Jump to content

FileMaker Advanced: Get(ScriptStack)


This topic is 1812 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

Link to post
Share on other sites
  • 8 months later...
  • 4 years later...

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?

Link to post
Share on other sites

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?

Link to post
Share on other sites

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?

Link to post
Share on other sites

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...

Link to post
Share on other sites

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.

 

Link to post
Share on other sites

This topic is 1812 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.