Disable Script Triggers?

[Squeaky Data]

How does the saying go? "With great power comes new responsibilities!"

Is it possible to disable script triggers while other scripts are running?

For example I have a Layout Script Trigger set for OnRecordLoad which runs in the middle of other scripts that go to that layout during their script process and interfere with the running scripts process.

It would be nice to have a script step to disable/enable script triggers while scripts are running.

[fabriceN]

Unfortunately, all the logic has to be in the script itself.

In your case, it's not easy because we still don't have a Get ( scriptStack ) function, so once the script is triggerred, it's too late to know if another script was running before.

What you can do is having a console-like variable, where every script writes its name at the beginning, and signs off at the end (I mean on each 'exit script').

It's... well... it's a way of doing it...

But frankly, missing features such as

- Enable/Disable script triggers,

- Get ( TriggerName ) (would return 'onLayoutLoad' for example - it appears in the Script Debugger)

- Get ( ScriptStack ) (the result would be what's at the bottom of the script Debugger)

makes work with Triggers a pain somewhere.

Edited January 14, 2009 by Guest

[Fitch]

I'm 99% sure I heard a FileMaker engineer at DevCon say that script triggers would only occur in response to user actions -- that they would not trigger if a script was doing the actions. I remember thinking at the time, "yes, that will make thinks much simpler."

This is very disappointing.

[mr_vodka]

Echo Tom. It was something I heard as well.

[Squeaky Data]

Thanks Fabrice,

I was starting to think about setting a global variable to "ScriptRunning" when one of my user scripts is running and clearing it on script exit.

I am starting to wonder how many places the script exit could be missed or bypassed due to some other error.

This has made a real mess where I have a user script opening a window and setting a specific window name which is later referenced by a close window by name script step. In the meantime an OnRecordLoad script has changed the window name and buggered the users close window script step.

I might revert to using "close current window" rather than a specific window name but I prefer the accuracy of closing a window by name.

Steve

[fabriceN]

sorry Fitch, no need to be disapointed, only actions that emulate user actions such as paste, insert... as well as layout/record/mode change (layout triggers) will trigger the scripts.

The Set Field script step for example is not aming at the layout layer but directly at the data layer and therefore doesn't trigger a script.

Edited January 14, 2009 by Guest

[Fitch]

Still, not what I hoped for. I'll have to RTFM on this one I guess.

Another way to disable all triggers would be to use a global variable (or global field for a multi-file system). Any script that is called by a script trigger can exit if $$trigger = 0; and any script that potentially invokes an unwanted trigger can start by setting $$trigger to 0 and end with setting it back to 1.

[Dave Graham]

Since Geoff Coffey showed me the light, I've begun eliminating context dependencies and my scripts are now nearly 100% modular. In other words, they typically spawn offscreen windows and set their context based on passed parameters, then close themselves up when they're done. This means that all of my scripted operations happen on developer layouts without any triggers.

[David Jondreau]

Spawning a new window will cause an OnLayoutLoad script to trigger.

I'm bumping into these issues today and it's pretty annoying.

[fabriceN]

I don't agree and I think onLayoutLoad and onRecordLoad are worth only if we can rely on the fact that the script is triggered EVERY time a layout/record is loaded.

I can see dozens of situations where this is useful (I was already doing it with a plug-in and a webviewer). Now it's not a problem to set a global field several TOs away to filter visible data depending on the active record.

[David Jondreau]

I'm not sure what you're disagreeing with.

I'm finding the lack of a Disable/Enable Script Triggers[] script step, and the management of triggers in general, to be annoying.

David's suggestion (using an off screen window to perform functions) doesn't stop the source layout's OnLayoutLoad script from triggering.*

*Though the general technique can be very useful.

Edited January 15, 2009 by Guest
*

[comment]

What do you do for OnWindowResize?

[myopus]

sorry Fitch, no need to be disapointed, only actions that emulate user actions such as paste, insert...

Thank's Fabrice to confirm. So the best way is to

forget these steps ? (whatever bad steps).

It seems to me that all other ways may be dangerous.

Gilles

[fabriceN]

What do you do for OnWindowResize?

sorry, I don't get it... there is no native trigger onWindowResize, as you already know.

[comment]

It's been barely a week, so I am not sure I really "know" anything yet. Anyway, I meant what will you do with LayoutProperties now?

[Brudderman]

Since Geoff Coffey showed me the light

In one of his books? I'd like to read about this if you can give me a pointer to the source.

Thanks!

[fabriceN]

I meant what will you do with LayoutProperties now?

Oh, this ! :

well, LayoutProperties 3 is still compatible with 10 (their are a few glitches though), and still offers things you can't do with 10 such as onWindowResize, and behaviours such as onAfterDisplay, onBeforeLeave, animated transitions, history and other things. It still makes it a snap to work with modal windows...

A new version is being tested now that will:

- be optimized for 10 compatibility

- bring the power of onLayoutLoad, onRecordLoad and onModeChange to FM 8.5 users.

- allow you to write the scripts in plain text directly in the properties (no need anymore to create those few lines long scripts...)

But don't worry, you'll know when it's released.

Fabrice

Edited January 18, 2009 by Guest

[comment]

But won't you need a script-triggering plugin IN ADDITION to the native triggers?

[fabriceN]

Of course, yes. I don't think native script triggers can replace plug-ins at all. Neither at the data level, nor at the layout level.

They offer events that webviewers were not able to catch such as Keystroke (the webviewer would re-evaluate only for some keys), and they have the nice False result that cancels the action.

For the rest, and especially triggers based on data modification, I'll rely on the plug-ins as always, untill FMI finally remembers they're selling a database-oriented software :

As for LayoutProperties, they won't need AT ALL native script triggers. It will still be fully compatible with 8.5.

There will be only one difference with 10 in the way you can write a script in the properties (using Set Field By Name, the real top new feature of the 10 IMHO)

Edited January 18, 2009 by Guest

[comment]

That's what I thought, I just wanted to be sure I'm not missing something. I am still looking for the top new feature myself...

[fabriceN]

... although it is not difficult to see what's on the top now (and was on the left before) :

[comment]

Definitely NOT that one:

http://fmforums.com/forum/showtopic.php?tid/200458/post/313992/#313992

http://fmforums.com/forum/showtopic.php?tid/200604/post/314672/#314672

[fabriceN]

was just pulling your leg... works great! :

Edited January 18, 2009 by Guest

[Dave Graham]

In one of his books? I'd like to read about this if you can give me a pointer to the source.

It was a session at Devcon, possibly in one of his books as well. Ultimately it's based around a few key concepts:

• Use finds instead of GTRR
• Passing multiple parameters and passing back results
• Creating modular scripts which perform simple tasks

Many developers have learned that passing multiple parameters is important. Most haven't harnessed the power of passing multiple results back. Once you grasp the benefit of both, you can modularize your routines to set up their own context, perform a simple task based on the parameters that have been passed, and return the results back to the parent scripts for further action.

[LaRetta]

Mikhail is great at breaking these concepts up, such as Options.

[Dave Graham]

Mikhail is great at breaking these concepts up, such as Options.

Indeed. In fact, looks like it great minds think alike.

I have a different approach to parameter passing, which makes for a much simpler custom function, but is far easier to screw up when writing the script parameter. I'll post a sample file soon.

[Brudderman]

Thanks for getting back with me on this. I have read the info on his blog and hope that some of the material is covered in his forthcoming book. I've been using the method presented in this video up to this point: http://www.filemakermagazine.com/videos/function-scripting.html