Script Triggers not telling me if a field really was modified

[jjjjp]

I want to do something that I had thought was fairly simple, but I can't get what seems like the obvious Filemaker tool to work for me. I need to be able to tell whether a number field in a settings table changed from 0 to 1 or 1 to 0 and to call a script that performs an action if and only if the field changed. The script's action depends on the direction of the change. Setting the OnScriptModify trigger to invoke a script would seem to be the obvious thing to do, but apparently if you change a zero to a zero or a one to a one, the script will be invoked even though the field didn't actually change. So I set another script to record in a global field, NumberOld, the active field contents using the OnObjectEnter trigger. A split second later, when the OnObjectModify trigger gets invoked, the first thing the invoked script does is place the active field contents in NumberNew. It then compares the two global fields to see if there was a real change and performs the necessary action accordingly. At least that's the theory. The problem is that for some reason the value in the NumberOld field does not accurately replicate the original value of the field. Sometimes it is correct, sometimes not. I prefer to display the field I'm monitoring as a pop-up menu, but I experience the same problem if I use an edit box or a radio button set.

The only solution I can think of is to give up on script triggers, turn the field into a button, and script the entire thing. But this would be an undesirable last resort, since all of the other settings are changed manually.

I thought I finally had a handle on triggers, but I guess not. Can anyone say whether I am missing a totally obvious solution.

You may open the attachment for a simplified version of my problem.

RememberNumber.fp7.zip

[comment]

The only solution I can think of is to give up on script triggers, turn the field into a button, and script the entire thing. But this would be an undesirable last resort, since all of the other settings are changed manually.

I am not sure of that: it's quite convenient to toggle a Boolean by clicking on it, and I don't think it is inconsistent with manual entry into edit boxes - as long as the field is formatted in a different way, e.g. a.checkbox. It's also the simplest solution.

To do it with script triggers, you can use the script parameter to capture the old value.

[jjjjp]

Thank you very much for that suggestion. Passing the value as a parameter does make sure that the script gets the correct initial value. I ended up, however, keeping the pop-up menu (with yes/no values) rather than checkboxes and invoking the script as a button rather than triggering it on entering. I did so because there are a great many of these settings appearing on more than one layout, some of which use even other control styles (radio buttons), and I felt I would have to change all of the control styles to check boxes--and all for the sake of the one and only one setting that needs to invoke a script. It seems that checkboxes aren't that compatible with other control styles in the way that they handle zeroes. In any case, it was not a big problem in the end to assume that by clicking on the one setting in question, the user indicates that s/he wants to toggle, and so my revised script asks immediately for confirmation that that is the intention.

Can you clarify for me under what circumstances Getting the active field contents in a script invoked OnEnter doesn't reliably work? I do so in a number of cases involving text fields using the edit box control style. I haven't had a problem (or hope that I truly haven't and won't), so I am wondering if the problem is with numbers but not with text.

[comment]

under what circumstances Getting the active field contents in a script invoked OnEnter doesn't reliably work?

I'm not aware of such issue. However, selecting from a pop-up menu does not necessarily activate the field.

[jjjjp]

I'm not aware of such issue. However, selecting from a pop-up menu does not necessarily activate the field.

In the attachment (expanded from my initial post), I see no clear pattern for when the field gets activated and when it doesn't. That goes for edit boxes just as well as it does for pop-up menus. I can know to avoid this situation in the future, but if there's a simple answer, I'd be interested to understand why things don't work as I would expect. When I set a global to the field contents triggered OnEnter, I am surprised to see the global contain the initial value in some cases but not in others.

RememberNumber.fp7.zip

[comment]

I'm afraid I cannot reproduce the problem (when using edit box).

[jjjjp]

I'm afraid I cannot reproduce the problem (when using edit box).

Maybe we're changing the fields in a different way. When there's a 1 in the Number field, a 0 in the RememberOld global field, and a 1 in the RememberNew global field, I select the 1 in the edit box of the Number field by swiping from right to left and then type 0 to replace the selected text. I expect to see a 1 in the RememberOld field and a 0 in the RememberNew field, but I see 0 in both.

[comment]

Tried that, but no. Make sure to commit the record in-between experiments.

[jjjjp]

I think you figured out where I was going wrong. When I am careful to click outside the field between experiments I appear to get the expected results. The pop-ups still act unexpectedly, so I will be careful to avoid using GetActiveFieldContents on entering with them, but it's good to know that text boxes are in fact OK. Thanks for your trouble.

[bcooney]

From the Script Trigger white paper, p. 34:

Interaction with popup menus, list, calendar, and auto-complete

A popup menu blocks other events from occurring. Therefore, an OnObjectEnter

script trigger will not run a script until after the menu is dismissed. The layout

object will not register that a change has occurred until an item is picked and the

menu is closed. Therefore, OnObjectModify, Save, and Exit scripts run afterwards

and will not interact with the popup menu.

When a field is formatted as a pop up list or drop down calendar, or is configured to

“auto complete using a value list”, the list or calendar will not display immediately on

field entry when the field is formatted to use an OnObjectEnter or OnObjectModify

script trigger. In the case of the field formatted with an OnObjectEnter script trigger,

the pop up list, drop down calendar or auto-complete functionality will display after

the script returns a “true” result.

[jjjjp]

Thanks for this. Good to know that the strange behaviour with popups is explainable.