1 of 1 people found this helpful
It is often necessary to disable script trigger performed scripts before changing layouts or records. This can be done as follows:
a) in every trigger controlled script that might be performed by your scripted action, enclose the entire script in an IF block similar to this:
If [ Not $$TriggersOff ]
Put rest of script here
Then, in your script that will trip these script triggers, set up your script like this:
Set variable [$$TriggersOff ; value: True ]
Go to Layout
Set Variable [$$TriggersOff ; value: False ] ----> this step can be put anywhere after the "triggering" step so long as it always executes to re-enable trigger controlled scripts whenever the earlier Set variable step disables it..
I feel that it is both presumptuous and foolhardy to follow with Phil's advice with something different, being the FMP rube I am, but here goes:
Could you, rather than using the New Window menu command (which opens a new window just like the one you are in, and re-fires everything) just create a script -
the first step: New Window, which then allows you to size and name it, etc,
then a second step: Go to Layout - of your choice.
This might avoid the actual opening a second window of the same one you are in. Plus you can size and place the window wherever you want, and rename the new window to something meaningful.
You can then place a button on the original layout to run the script, then close the second window when finished, with the original layout still there.
I do this for lots of temporary "side trips" for certain work flows.
FilmUser, what you describe is what Christopher Wagner is already doing and the new window script step is what is tripping the script triggers and thus producing an undesirable delay. My approach still uses the new window, go to layout script steps, but only after temporarily disabling script triggers by setting a global variable to True.
Phil - So, in other words, scripting a new window followed immediately in the script by a layout navigation, doesn't escape the triggers set in the load of the original window, which would fire from the regular menu command of New Window?
OnRecordLoad in the NEW window is tripped as the new window will initially have the same layout as the current window. I think OnLayoutEnter on the new window and OnLayoutExit on the old window might also be tripped, but I'd have to check.
This is why I have developed the habit of enclosing trigger controlled scripts inside such an If block, all referencing the same global variable. that way I can set this variable to True and disable all triggers until I clear its value.
Phil is right. No matter what when you create a new window all the script triggers fire. OnLayoutEnter and OnRecordLoad. I'm pretty sure OnLayoutExit does not because I don't ever remember seeing it in the script stack in the debugger.
My next question Phil, is why enclose all your entire script trigger scripts in an if statement? Wouldn't a
Be just as effective and maybe a little more readable? Just wondering on this one.
Lastly at what point does server send the client the text of the script. Is this done on connection, layout load, or when called? Most of my performance hits are over WAN.
One last thing, unrelated, for being a Apple product, the filemaker website and forums sure suck to use from an iPhone or iPad!!
Your 6 = my 1/2 dozen
I don't really know being a fellow user.
One last thing,
Yep and if you check the Feedback section, you'll find that you are not alone in that. I cannot say much being under NDA, but I can confirm that the folks responsible for these forums are not unaware of this issue.
You could also use "go to related record(s)" in a new window. It'd require
- A related table guaranteed to have at least 1 record in it, for any record in the table for your 'original' layout
- A layout for that other table with no 'OnLayoutEnter' script triggers
It might be easier to implement this as a solution to the problem
1 of 1 people found this helpful
Since 2014--when this thread started, I've learned a new trick that also works.
Have your script enter find mode, then open the new window and change layouts before entering Browse mode. This would be an option for when GTRR isn't appropriate.
Ah, but will this not leave the original windows/layout in Find Mode, after switching windows?
but the script can put the window back into Browse mode after window and layout "stuff" has been done.
Yes, but I would like the new window to take focus, which involves shifting forth and back?