Go/No-go test for script execution?

[Rich S]

One of the problems I worry about with my current solution is that a lot of it is script driven...which has me scratching my head as to how to prevent the end user from accidentally clicking another button which would cause a second script to start while the first one is still running.

I've come up with the attached, quick-'n'-dirty script that I might use to prevent such a problem; it would be inserted at the beginning of every script so before the script can execute, if it "sees" that System::gScriptControl = 1 then it terminates the second script and lets the first one continue running without interference.

At the end of each script would be:

SetField [system::gScriptControl;0]

...to reset the trap.

Is there a better or more elegant way of handling a potential script conflict problem or is this the simplest way to deal with this issue?

script.pdf

[Vaughan]

I think you're solving a problem that does not exist.

Run scripts that should not be interrupted with Allow User Abort [off]. Never use the Halt Script step.

[Rich S]

I think I need a little education here, Vaughan--please see the attached and where I highlighted the Halt Script step.

I was told that as good practice, an If test shouldn't be left "hanging", that it should be properly terminated. Am I to infer from what you're saying that it's not necessary (or even true) to require that and that I can just do away with Halt Script step altogether (as in this example) because it's superfluous?

Find_Company_Names_script.pdf

[Vaughan]

was told that as good practice, an If test shouldn't be left "hanging", that it should be properly terminated.

Scripts don't need to end with an Exit Script step, unless a script result is being passed. In the pdf the script has an exit step at the end without a result, so it's superfluous. FMP exists scripts when they end whether there is an exit step or not (what else can it do?)

IMHO the Halt Script step is poor practice because it's an unconditional stop, and that could have unintended consequences.

You've got the user in a looped script to control a process. They run a seemingly inocuous script that ends in Halt -- bam, the looping script is ended too.

I'm also passionate about error capture. Turn it on when it's needed, then turn it off straight away. If there is an error running a script I want to know about it.

...

Set error capture [on]

Perform find

Ser Variable [$error ; Get( LastError )]

Set error capture [off]

If [$error = o]

...

[Matthew F]

I'm also passionate about error capture.

I love this quote.

[Vaughan]

Yeah, I'm a romantic from waaaaay back. :

[bruceR]

Scripts don't need to end with an Exit Script step, unless a script result is being passed.

True; but FWIW I have gotten into the habit of almost always putting exit script at the end for debugging purposes. Step all the way through script then look at variables etc. before leaving the script.

[lawaid]

Hi Vaughn:

Run scripts that should not be interrupted with Allow User Abort [off].

I'm having trouble making that work. I built a Test script that sets Abort to OFF, then enters Pause indefinitely. A separate button resumes the script (with the "Current Script" option set to 'RESUME' in the Button Setup), and the Test script completes its execution.

During that Pause however, any other buttons I click (all using the 'PAUSE' option for Current Script) will execute their scripts. When those scripts terminate, the Test script revives the Pause state. From there, I can terminate the Test script.

I'm probably missing something, but is there a way to prevent a secondary script from executing when a primary script is running? Does it require a "trap" like Rich was asking about?

I tried having a Loop in the Test script, but no change. Experiments with buttons using the 'HALT' and 'EXIT' options in Button Setup indeed halted and exited the Test script. (thought I'd check anyway)

Any help would be appreciated. Thank you.

[David Jondreau]

I just started using a $$var for exiting OnLayoutEnter triggered scripts when creating new windows in other scripts.

//Main script

Set Variable[$$triggerOff;1]

New Window[]

Set Variable[$$triggerff;""]

//triggered script

If[$$triggerOff]

Exit Script

End If

Now I don't think that will solve your problem of called scripts continuing your paused script, but that shouldn't be happening.

Paused scripts should stay paused, if you have Allow User Abort[Off].

I add Allow User Abort[Off] at the beginning of every script in production.

[Vaughan]

During that Pause however, any other buttons I click (all using the 'PAUSE' option for Current Script) will execute their scripts. When those scripts terminate, the Test script revives the Pause state. From there, I can terminate the Test script.

Once the script attached to the button runs, the original script should be left as it previously was. Do any of those scripts attached to the buttons have allow user abort [on] in them? If so, that's the problem.

I'm probably missing something, but is there a way to prevent a secondary script from executing when a primary script is running?

FMP has to allow secondary scripts to run otherwise the scripts feature would be pretty useless. It'd lose much of its current flexibility because you couldn't have sub-scripts: no more script modularisation and code re-use.

[lawaid]

Thank you both, and your point is key, Vaughn, about secondary scripts having the ability to run. That bias is in place for a reason.

I've been setting a variable as you recommend, DJ, and it looks like that's the way to go. Rich's post prompted me to ask whether a better approach existed.

Much appreciation.

[Vaughan]

DJ's technique was developed to allow control over script triggers -- for example, to control whether the script proceeds after it has been triggered when changing layouts. (Note that I said "the script proceeds" rather than "the script runs" because there is no way to stop the script from running once the trigger event has occurred.)

OTOH I think that your issue is about navigation and control and IMHO this requires thought and planning rather than a method to prevent scripts from running.

For instance, if the user is in a window that is meant to be "modal" then give it a custom menu with the Close command and the scripts menu removed or controlled to prevent the user from running other scripts.

I'm reluctant to rely on a method that requires trapping steps at the start of every script; one day a developer will forget and then the whole system will break down.

Also, global variables don't come under the security umbrella so there is nothing to prevent a determined user from changing the value of a variable and allowing unexpected actions to take place.

[lawaid]

All good points, sir ... I need to give it more thought.

Thanks again for your time and providing such good details to consider!