Get (fieldname) for dynamic field ID doesn't work.

[Oldsneekers]

I have a number of large text fields that take up the right half of the screen. To permit access to all the fields and at the same time allow the user to see the full text, I stacked the fields and have buttons just to the left that are scripted to go to the appropriate field. However, this alone can allow the user to forget what field he/she had entered. I planned to have each of the "go to field" buttons to be calc fields that become bold when the corresponding field is entered, and plain if not. Calculation as follows (for the button to navigate into the TextReason field)

Case( Get(active field name), "TextReason"; TextStyleAdd( "Reason", bold); TextStyleAdd( "Reason", plain)).

As a calculation field defined by the above function, it does not work, ie the field remains blank. As a text field and button scripted to Setfield(Navbutton; Textstyleadd(Get(ActiveFieldName), bold) , however, it works, ie the name appears in the label field but the problem is still (with the setfield method), when the user exits the selected text field (ie selectiong another function, button or inactive layout object), the bold field identification text remains.

Any suggestions to achieve the desired result, (highlight a button or label for a corresponding active field)?

Many and continued thanks.

[-Queue-]

It seems that you're trying to use Case like you would Choose, which will not work.

Try

Case( Get(ActiveFieldName) = "TextReason"; TextStyleAdd( "Reason", Bold ); TextStyleAdd( "Reason", Plain ) )

or

TextStyleAdd( "Reason"; Case( Get(ActiveFieldName) = "TextReason"; Bold; Plain ) )

I haven't tested these, so they might not work. FM is very touchy about using Get(ActiveFieldName) in a calculation, even unstored, since calculations don't update until you exit the field.

[CobaltSky]

I haven't tested these, so they might not work. FM is very touchy about using Get(ActiveFieldName) in a calculation, even unstored, since calculations don't update until you exit the field.

I'm afraid this theory is correct - ie it won't work because the mere act of entering or exiting a field will not prompt reevaluation of the calculations, even if they are unstored. A screen refresh, mode change, layout change or record change (including navigation between records or modification of a referenced field in the current record) is required to prompt reevaluation and therefore the Get(ActiveFieldName) function is unsuitable for use in the formula for a calculation field in this and most other instances.

You can get part of the way towards the functionality you are aiming for by creating a fully scripted interface and ensuring that everything on the layout that the user might click on (including the 'background area') is defined as a button which runs a script that, as well as performing the assigned function, also updates the fields that provide the text for your buttons.

If your fields are only for display (and not for data entry), a better solution might be to place only a single utilty field at the right and have your buttons copy the text from a given data field into the utility field, then define your button text calculations along the lines of:

TextStyleAdd("Reason"; (UtilityField = TextReason) * 256)

With this set-up, the button text (regardless of whether the calcs are stored or ustored) will always update to match the current content of the utility field.

However if you require that the users be able to enter the field/s and edit the data, then the foregoring suggestion will not avail. In that case, I'd suggest that you consider storing the various fields in a related table and using a portal to summon up the appropriate field, according to which button is clicked. I've attached a quick demo which shows an example of one possible implementation of this kind of technique.

FieldSelection.zip

[Oldsneekers]

I appreciate all the work that you have put into this problem, but the problem remains, allowing the user to enter one of several stacked fields and enter text with a label that changes with entry and (most elusively) changes with exiting the field. I think I wll have to change the wording of the field label to state "last entered data" or some such thing to legitamize the fact is stays bold.

Again, I appreciate the input. (The internet still amazes me. While I sit watching the ice shimmer outside my window, I'm communicating with someone from the various corners of our humble blue globe.) GW