Loosing my Index...

[Addam]

I have a field called "Layouts" which is a calculation that show's the current layouts in the database "LayoutNames("Yours.fp5")".

Now... the purpose of this was if I created another layout, it would show in the list without me having to create another button to get to it (I'm controling all navigation).

For some reason it doesn't show the newly added layout(s) unless I go into "Define Fields" then it recalculates it. Is there a way to reindex a field? or keep it running?

[Kurt Knippel]

Make it UNSTORED.

[Addam]

Hey Kurt!

Thanks! That works! BUT!! Let me did a little deeper. I'm trying to use THAT field as a value list for a pop-up menu. When I do that, I get "<index missing>".

That's how most of this came about. Forgive me for not being more clear. But your suggestion is an alternative for me. I can always just show a list of current layouts for viewing... I would just like to be able to grab the index and pick a layout from a list.

eehh... we shall see!

~Addam~

[Vaughan]

Only "Stored" calculations can be indexed. If a calc uses a global field or a related value, it CANNOT be stored, so it cannnot be used for value lists.

[CobaltSky]

To solve this problem, you will need to create a mechanism by which the list can be updated whenever layout names are changed.

I suggest that you consider dispensing with the calculation and instead, place the layout names in a text field (preferably in a related file of global data - but this is not essential) then place your calculation in a Set Field [ ] script step, within a script that you run after every time you make any changes to layout names. The script will then automatically refresh the indexable field on which the value list of layout names is based.

If you are concerned about the possibility that you may overlook to call the script at some point, then as a failsafe, I suggest that you include a call to it (as a sub-script) from within the start-up script of your file, so that every user session will always start out with up-to-date layout navigation lists.

[Kurt Knippel]

Ray's suggestion is right on! Using the calculation is just bound to cause all kinds of issues like the one that you experienced.

[CobaltSky]

A side-benefit of the scripted approach as against the stored calculation method, is that the Layout names list need only be stored once in total, rather than once for every record - which is a saving on file size and other overheads.