FileMaker Advanced: Get(ScriptStack)

[ferdly]

Hi All,

When we get good at Code Reuse the list of scripts in the stack (wonderfully displayed for us in debugger) can get somewhat lengthy.

In debugger you can watch.

Then comes the the stage where you need to "let it rip" a little bit.

For that I use an $$error session variable and I put in an error message and a series on Get() functions for context. I now include Get(ScriptName), and I think I should be able to also capture Get(ScriptStack) top-to-bottom from active to calling to calling and so on. Also, this function should be able to take an optional parameter (or somehow offer both options) to return the Stack as a List of just the Script Names and as a List of Script Names with their Parameter(s).

FWIW: $0.02

[Thomas Seidler]

You've got my vote on this. I think a lot of us want a ScriptStack Get param.

T

[Thomas Seidler]

Once again, 5 years on, I find myself wanting this available still...!!! It could have the identical format to delivered data in Script Debugger: Script Name ( File Name.fmpXX { , Parameter: *quoted parameters* } ). We could happily parse it up, just to have that list available.

I've realised logically it is impossible to do accurately via the $$CallStack approach, which is also exceedingly laborious: every script entrance but add to stack, and before every exit/halt the stack must be exited. I was thinking (and in my latest feature req submission stated) that Pause/User abort is the doom of such scripts. And I think it probably is, but if you turned user abort off period, you could remove from stack before Pause and add to stack after pause, but that's still not quite going to be right (as far as I can think, cos if a new script comes in and resumes old scripts etc., the stack won't be quite right all the time).

Mmm... does no one else want this single function?

[Wim Decorte]

What would be a practical use for it?

[Thomas Seidler]

Ah, yes, I didn't mention, I realise I could also really use source of Script if known, as per Script Debugger: e.g. Button/OnKeyStroke etc - the primary area (as I recall) where I have found myself wishing I could check the stack was from ScriptTriggers...

So if you had an OnRecordLoad or OnLayoutEnter script you didn't want to run if any scripts were running, that any script would by default have last word... so within the Script Trigger:

If ( ValueCount ( CustomFunction_ScriptStackHandler ( Get(ScriptStack) ; "RemoveSomeScriptTriggers" ) ) ): Exit Script  // override default behaviour controlled by Script Triggers

Else: Continue with Script Trigger

Of course variables can be set, and I'm aware many do have pretty thorough systems for them, and the $$ScriptTriggersOff approach, but it's a little trixxy don't you think? I like your script trigger demo with Mislav Kos. Do you have a preferred approach for controlling ScriptTrigger behaviour simply?

[Wim Decorte]

I think the variable approach is far less tricky.  In your proposed approach you'd have to hard-code the script name which does not make it safe to change it.

[Thomas Seidler]

No, you'd not need to hard code, the Get(ScriptStack) would return the call object if known, i.e. button or Script Trigger (i.e. all the info available to Script Debugger), so you'd just have a custom function to rip the Script Trigger scripts (or what have you) from the stack, and hey presto, i know if there are other scripts running (above and beyond Script Triggers) without any further ado. That said, in the meantime I'm all for solid variable solutions, can you post a link to your preferred one as a solution to this problem?

You'd write custom functions on the back of it that would tell us things like: CF(ScriptStack; "ScriptTriggers") and return a value separated list of which ones are in stack. If my script GoesToLayout and hits the start of a table triggering OnRecordLoad, and then GoesToLast Record, now I only want it to run the last instance of OnRecordLoad... but not twice. So I can check to see if another instance of OnRecordLoad script trigger exist, and just run the last one... etc?

[Thomas Seidler]

i realise i have an unusual approach to ScriptTriggering that's probably not helping things. For various reasons I tend to use zippScript etc, to fire off Scripts from calculation boxes rather than by actually directly calling them, it allows me more script modularity etc, but comes perhaps at a price of clarity and control...

[Wim Decorte]

Hard to imagine why you would use a plugin to triggers scripts instead of using the 30 or so handled events...

But it sounds like you are searching for a solution where you:

1) first configure events to trigger a script

2) but then don't want them to trigger when the events actually happen.  Probably when other scripted actions are happening

To me it sounds like an over-reliance on triggers.  Could be solved fairly easily by the variable approach to shortcut the triggered scripts, but also adjusting the workflow so that any scripted action happen in the background, in windows and layouts that do not have those triggers set up.  Unless you've set them up in the field definition level etc.