I made a quick test.
First a script to go to a layout:
Set Variable [$r; Value:MBS("Log"; "before")]
Go to Layout [“test Copy”]
Set Variable [$r; Value:MBS("Log"; "after")]
Second a script for the LayoutEnter trigger:
Set Variable [$r; Value:MBS("Log"; "Layout Enter")]
And the log shows:
23.04.15 21:59:01,295 FileMaker Pro: before
23.04.15 21:59:01,297 FileMaker Pro: Layout Enter
23.04.15 21:59:01,298 FileMaker Pro: after
so the answer for FM 13 is: They are not stacked!
I think the term "stacked" is not accurate in this context. Scripts running in a client are single threaded, not multi-threaded, which is what I think you are asking.
Script triggers will fire according to how they are configured during the course of a script running in the client, but another script called from a separate event will have to wait for the first one to complete before running.
The term "stack" is more applicable to a script performing a sub script, and you can see those stack up in the script debugger. And when, for example, you halt a script, the entire stack collapses.
Clever test Christian, thanks !
and another good example how to use your plugin.
So it's time to build some traps to prevent this scenario, it just never occurred to me this could happen, but now I'm warned
So Mike, just to be sure: in my example the script for a New record would wait until the other script is finished and the sequence that Christian shows is purely the result of the trigger on that layout
I simply expected the trigger to fire.
For plugin script calls I can tell that they usually wait for current script to finish before executing.
There is a bit of behaviour that can run a script - and a series of subscripts while the first script temporarily pauses.
Put a pause indefinitely, have a script attached to a button and see that the options to Pause the current script can go and do all kinds of things then come back to your paused point where you can either run another loop of scripts or continue with your first one...
Yes, I realize that option, but in this case there are no pauses or triggers involved.
Today I give a training on our solution and I will test this in a multi-user environment and have 10 people starting this script simultanuously, then check the results and see if I can reproduce this error.
If Cntrl-N is defined in a Custom Menu, then that is your "Trigger", where you can at least control if the current script is paused
> Yes, I realize that option, but in this case there are no pauses or triggers involved
I don't think you can even run a user-initiated script (via a custom menu, or a button click) while a script is running(not paused)...even with Allow User Abort [ On ] though of course, you have that set to Off, right?
Menu items are greyed out during script execution (custom or otherwise).
Using a training session on our solution, I mimicked this situation with 7 concurrent users who all fired at the same moment:
• each user started from a single record they just created to prevent record locking during this test
• started the complex looping script and create 96 child records
• while this is running, hit Cmd-N to create a new record.
The results were very clear: Cmd-N is simply ignored while the other script is running, not paused or queued, just not fired.
The only case it did run was when Cmd-N was continually pressed and still in that state when the looping script finished, at which time it did create (just one) new record.
So, this is a re-assuring result but does not solve the initial problem. I will look over the shoulder of this one user where this is happening to see her exact worklfow, but with the other thread in mind (on erratic server behaviour), I will keep an open mind on hardware issues for that client machine.