Exit Script - unexpected behaviour?

[IdealData]

I've been programming FMP for 10 years but I never used the "exit script" until recently.

My solution had to permit a script to pause but still allow the script to be invoked again from the same button as I am validating the content of the field and the fields on the layout. In order to stop unnecessary recursions of the script I tried an "exit script" if I already had a record of the script running (held in a global).

The peculiar behaviour was that if the script had, at any point, been exited then the script that was paused would also terminate as soon as it was resumed, thereby failing to perform the validations.

I expected FMP to handle the scripts almost as a stack of tasks to be executed on resumption, and that the "exit script" was pertinent to the current instance of this script, not all those that have the same name.

All this is in FMP6, so it may not be the same in 7/8, but I hope it is. The help system is a little vague

"Forces sub-scripts or external scripts to stop immediately and return to main script."

and this does not explicitly state that it will "kill" all other occurrences of the same named script when they resume.

My workaround is not to use "exit script", and continue, as I have for the last 10 years, to let all my scripts execute to completion.

Hope this makes sense to some of you.

[John Mark Osborne]

Situations like you describe are typically handled with a looping script. Place all of the steps you want to repeat within the script, including the Pause/Resume Script. Use the Exit Loop If step to determine if the fields are "validated". If they are, you exit the script. Otherwise, you loop again.

You can even have a button on the layout with the single step Resume Script attached to resume the paused script. Here is an example of a script that I wrote yesterday for a client. I've paired it down to just the looping portion of the script.

Loop

Pause/Resume Script [indefinitely]

Exit Loop If [not IsEmpty(MYTABLE::Field1) and not IsEmpty(MYTABLE::Field2)]

Show Custom Dialog ["Some Fields Empty"; "All fields on this layout need to be populated."]

End Loop

[Ender]

Hey what's the dealio, ideal?

You can use Exit Script to exit the current instance of recursive or stacked scripts and keep the script running. Attached is a simple demo illustrating this. A script can also be run with pauses and multiple instances running opened via buttons, and have the Exit Script step only exit the current instance.

I suspect your problem is because the button that executes the script is defined to "Exit Script" or "Halt Script", which would exit the active script before starting the new one (Halt Script exits all running scripts.) The button should be defined to "Pause Script" if you wish any active running scripts to complete after the button's script is finished.

RecursiveScript.fp7.zip

[Søren Dyhr]

I have wrecked my brains to see any point in the Exit Script step's return parameter, beyond the transfer of $$globals from one file to another... I have during the time from the release intil now, more and more become convinced it's made to satisfy just a certain bread of developers - When it comes to it, is it a costless feature added purely of cosmetic reasons.

Halt script has it's virtues as Ender mentions, e.g. Where would you put the Exit Script[ paramter in this recursive script, if it weren't in a $$global value??

If [ IsEmpty ( Get ( ScriptParameter ) ) ] 

     Perform Script [ “New Script”; Parameter: test::aField ] 

Else 

     Set Field [ test::aField; Sqrt ( Get ( ScriptParameter ) ) ] 

     If [ test::aField < 3 ] 

             Halt Script 

     Else 

             Perform Script [ “New Script”; Parameter: test::aField ]

     End If 

End If 

...what Halt Script here does that it prevent the script to reach each of the stacked End If's ...which is pretty neat if the number of recursions is large (not that it'll eat many calories from the processor but's irritating for the debugging developer to watch). Now ideally would such a recursion be called as a sort of service, with the expactation to get something returned ...if you just you could have Exit Script( to say ....as long as being inside a recursion is it going to behave as Halt.



So what I ask for is that Exit Script with a paramter zaps all layered scripts except the original calling one, which are to get a paramter back!



Well if we turn our script into using Exit Script with a paramter is it again tied to the stacking going on:

If [ IsEmpty ( Get ( ScriptParameter ) ) ] 

       Perform Script [ “New Script”; Parameter: test::aField ] 

Else 

       Set Field [ test::aField; Sqrt ( Get ( ScriptParameter ) ) ] 

       If [ test::aField < 3 ] 

              Exit Script [ Result: "1" ] 

       Else 

              Perform Script [ “New Script”; Parameter: test::aField ] 

       End If 

End If 

Show Custom Dialog [ Message: Get ( ScriptResult ); Buttons: “OK”, “Cancel” ] 

...give it a whirl with the debugger, and see what happens with a pretty large number such as 9999999999, which are bound to give some recursions at least.

Several dialogs shows up during the run, but only the innermost carries any message at all!

It seems to me that $variables kind of having made the Exit Script's paramter feature redundant in it's infancy!

--sd

[IdealData]

Thanks guys, and I know I'm dealing with the best that's around, but to put things in perspective I have a major in-house solution with 10,000+ scripts. I'm quite okay with nested loops and Nth level sub-scripting.

The behaviour I witnessed was in FMP6 and I used the debugger to trace what was happening.

The MAIN script was invoked from a button and then called a sub-script (SUB) and then paused.

MAIN script was invoked again in the same way, then called SUB, but SUB was instructed to EXIT SCRIPT when it checked if it was already running (stored previous occurrence in global)

When SUB was resumed it exited the script at the next script line, before running to end.

My point is that although SUB had been called twice and the second occurrence was exited, this also exited the first occurrence once it was resumed.

I worked around this by changing MAIN to detect if SUB was running BEFORE invoking SUB.

[Søren Dyhr]

I worked around this by changing MAIN to detect if SUB was running BEFORE invoking SUB.

When designing a button on the layout do you have the option to drift from the default "pause" current running script, into say HALT...or Exit...

This means that testing is a bit over the top if Halt is used, unless you in the previous script have turned "Allow user abort" off?

--sd

[Ender]

I think I already covered this, so if you want specific analysis, maybe you can post a sample that shows your trouble.