Trouble incorporating Suppressible Triggered Scripts

[DeathRobot]

Hi. I am trying to incorporate the 4 custom functions from filemakerstandards.org that are set up to suppress script triggers:

 

http://filemakerstandards.org/display/bp/Suppressible+Triggered+Scripts

 

but am having a bit of difficulty and inconsistent results.

 

Several of my layouts contain an onLayoutEnter trigger that calls a script. At the top of this script, I've put:

 

If [not TriggersAreActive]

     Exit Script []

End If

 

On a script that contains a go to layout step, and where I want to suppress the onLayoutEnter script trigger, I've placed:

 

Set Variable [$!; Value:TriggersDisable]

     (then the parts of the script that go to the layout)

Set Variable [$!; Value:TriggersEnable]

 

However, the values are not being updated correctly. When I watch the values of the custom functions in the data viewer, before doing anything, I see:

 

TriggersAreActive = 1

TriggersDisable = 0

TriggersEnable = (nothing shows up here)

 

As soon as I begin my script, TriggersDisable changes to 1, even though it has not been called (the first script step is a getActiveModifierKeys step):

 

TriggersAreActive = 1

TriggersDisable = 1

TriggersEnable = (still nothing here)

 

When the TriggersDisable step happens, values are updated to:

 

TriggersAreActive = 0

TriggersDisable = 1

TriggersEnable = (still nothing here)

 

As soon as the next script step is called (in this case, a set $variable to windowWidth), TriggersAreActive changes to 1:

 

TriggersAreActive = 1

TriggersDisable = 1

TriggersEnable = (still nothing here)

 

Of course, the onLayoutEnter script trigger is called. When the original script resumes, and we get to the TriggersEnable step, values are:

 

TriggersAreActive = 1

TriggersDisable = 0

TriggersEnable = (still nothing here)

 

Many questions:

1) Am I calling the functions correctly?

2) It appears it does not matter what the local variable ($!) is called, correct?

3) Why is the value of TriggersEnable always null, and never 0 or 1?

4) Why are TriggersAreActive and TriggersDisable changing values, seemingly on their own?

 

Thanks in advance for any help with this!

 

Michael

 

[jbante]

Showing the TriggersDisable and the TriggersEnable functions in the Data Viewer will definitely lead to some funky behavior. Those two functions set global variables that the TriggersAreActive function looks at to know what to do. Every time the web viewer evaluates, it's as if you're re-disabling and enabling triggers in subscripts in potentially unpredictable ways. Use the Data Viewer to watch what the variables are being set to, not what the functions (except TriggersAreActive) return. Otherwise, you are using the functions correctly in your scripts.

 

You are correct that it doesn't matter what the local variable is called. The Set Variable steps are just a benign opportunity to call the functions without any possibility of affecting anything else. The convention of using $! was chosen to be as visually unobtrusive as possible, but I've used $ignoreMe from time to time as a more self-descriptive alternative.

 

TriggersEnable doesn't return the same True/False values indicating success/failure as TriggersDisable because we just weren't thinking that much about it. We probably ought to revise the TriggersDisable function to also always return null to match the TriggersEnable function and typical usage.

[DeathRobot]

Thanks very much for your reply. My troubles started when I entered Find mode on a layout, and the onModeEnter trigger didn't fire. I put the functions in the data viewer, and started on the test above. Seems like I must have missed a TriggersEnable in some script then. I will track that down, but it leads to one more question. What is your suggested use of TriggersReset? Do you put that at the bottom of any script that uses TriggersDisable (though I would have the same error I'm having now, where I probably exited a script before getting to the TriggersEnable step). Or do you put it at the top of every script? Or…?

[jbante]

TriggersReset should only be used for troubleshooting purposes, usually when you're trying to track down where you have a TriggersDisable call without a matching TriggersEnable call. When you only use the TriggersDisable/Enable functions, they will respect the trigger state set by any parent scripts, i.e., if a script turns triggers off and calls a sub-script, the sub-script will not re-enable triggers no matter how many times it calls the TriggersEnable function. The TriggersReset function does not respect the existing state. Since we can't reasonably be expected to anticipate all the future uses of a script, we have to assume that it could be a sub-script of another script at some point, so TriggersReset is never the right function, except possibly in a developer utility script that never gets called in the normal operation of the application.

[DeathRobot]

Thanks so much for the explanation. I didn't realize that TriggersAreActive will ignore TriggersEnable called in sub-scripts. This all makes sense now. Appreciated!