Pause, Resume, Exit, or Halt the Current Script?

[kennedy]

When you specify a Button to Perform Script, there is an option to choose to Pause, Resume, Exit, or Halt the Current Script. The FMP help is silent on this option... so, I am left guessing what it means.

Does it mean, if a script is running, and someone pushes this button, then you first either Pause, Resume, Exit, or Halt the running script, then you Perform the Script specified by this button??

If so, what are the issues with choosing different things?

For example, if I have a button that is supposed to take me to a new top-level entry point in a new file, presumably I wouldn't want to keep performing whatever script I was performing before. So, should I choose Exit or Halt?

If I set up a button to go to Find Mode, again it seems it should Exit or Halt any running script. True? Then again, I guess if you did Pause, you could modify the found set and then let the running script proceed on it... seems error-prone.

When would you ever specify Resume?

What is the difference between Exit and Halt in this case?

Wouldn't it be safer if it defaulted to Exit?

I have a feeling I am not interpreting it right at all.

Thanks for enlightening me.

[CobaltSky]

Does it mean, if a script is running, and someone pushes this button, then you first either Pause, Resume, Exit, or Halt the running script, then you Perform the Script specified by this button??

You are on the right track here.

Pause is the default, and appears to be the least 'dangerous' - until you realise that if your buttons all use this option and the user clicks them in succession, you can end up with a backlog of partially executed scripts waiting to be resumed. Whenever the user presses enter (by which time they may be far away in another part of the database) the most recently paused of the bacllog of scripts starts running. A recipe for disaster.

Resume ensures that the original script will complete, by having it continue from where it left off after the user triggered script completes (unless the user triggered script has a 'Halt Script' step in it. Whether this is appropriate or not is entiresly dependent on the nature of the script. An example of where it would be appropriate would be for a button which zooms the window. There is no reason why clicking on this button should stall or cancel any other script which is currently executing.

Exit teminates the script which is currently running (which may be a sub-script) but not any other scripts which may be paused or set to resume when the current script completes.

Halt terminates all other scripts whether they are running, paused or set to resume.

The difference between Exit and Halt parallels the difference between these two script steps. Exit is specific to one script only, Halt is universal.

Hope this helps to clarify the situation for you...

[kennedy]

Thanks for the explanation, Ray. Your example for Resume was particularly helpful... I'd love to hear good examples for when to use the other three.

In particular, Exit seems strange... unless its a button designed to be pressed specifically to exit that script. And given your comments, Pause doesn't seem good at all unless the script being called explicitly resumes or halts the existing scripts.

Let me throw out a few examples, and see what the right choice is...

1) I have a tab that goes to the "main" layout of a different file... I would think it should Halt any running scripts... the user is choosing to go to a different activity. If you did Resume, what would happen now that you're in a different file?

2) I have a button that goes to a different list layout of the existing file; the user wants to see a different set of columns, perhaps. Resume here would seem reasonable.

3) I have a button that goes into Find mode. Pause might be the right choice here, as long as your script that does the Perform Find follows up by resuming the script that was paused by going into Find mode. How would I make it do that, assuming it was the right thing to do? (see #4)

4) I have a button that does Perform Find when in Find mode. Any script that was running was running *in* Find mode. And this button will be exiting Find mode. Thus, it seems reasonable for this button to Halt running scripts, Perform Find, and then resume the scripts that were running prior to the Find (see #3). How would it do that?

Am I on the right track here, or am I out in left field.

Thanks for enlightening me!

[Fitch]

I think FileMaker was trying to make things easier on beginning scripters, but just made it more confusing. IMO, the default for a new button should be Exit, not Pause. It's very rare that I use the other options. I'd rather explicitly control the flow of my scripts.

[CobaltSky]

Hi,

Your first two examples are reasonable and appropriate uses of the Halt and Resume options.

There is a fundamental limitation, in that when you specify what is to happen when a button is clicked, you cannot know which script may be running at a time when the user may click the button. With some scripts, such as your example, you may be confident that no matter what script is running it should be safe (and desirable) that it automatically resume.

It is because you cannot be sure which script a button may be interrupting at any point that the pause option is provided. This option is really a non-option, as it leaves it in the hands of the user to work out what is going on and decide what they want to do about it. If you're programming a database for your own use, this might be a reasonable default - but developers working to professional standards will rarely be comfortable to leave things to chance (or to user 'intuition'...) in such a way.

Hopefully that gives you a beeter idea why the 'Pause' option exists, and when you may consider using it. However, regarding your point 3), you cannot resume a paused script from within a subsequent script (unless you have access to external functions such as are provided by the DialogMagic plug-in). Scripts can cancel all scripts including themselves (using the 'Halt' script step), can Pause/Resume themselves and can trigger other scripts, but there us no standard 'Resume other scripts' script step.

The distinction between 'Exit' and 'Halt' is an important one. Exit completely and permanently stops the current script from running. If you want it to run again you must start it fresh. Halt is even more extreme; it completely and permanently terminates ALL paused or running scripts including external scripts. So the use of Halt you were thinking of in your fourth example would not suit, as there would be no way to resume the scripts again later. Exit would not do either. Resume would resume them automatically and pause would wait for the user to resume or cancel.

A perfect use of the Halt option would be for a 'Refresh' button which cancels all activity and takes the user back to the start of the file. Another would be for the launching of a complex script with user feedback which will substantially change the states of the file along the way and leave the user on a layout in another file (eg a summary report). Halt would be appropriate here because the context after the script the button will run will be so altered that any other script which was resuming would be unlikely to have desirable or predictable results, continuing/operating from such a different context.

Exit, on the other hand, is a lighter touch than 'Halt', and might be appropriate, for example, for a button linked to a script which calculates some summary results and places them in global fields on the current layout. You may prefer that the most recently run script (eg the one which brought the user to the current layout) be terminated when this calc runs. But you may not wish to cancel any other scripts which were previously paused (eg if the script that brought the user to the current layout was attached to a button which may have paused another script (scripts can be paused 'several layers deep').

I could give you more examples, but from here on in it gets fairly complex. Hopefully the examples above will give you a slghtly clearer picture...

[kennedy]

Tom, Why do you most often use Exit rather than Halt? In what situations do you not want the currently running script to resume, but you do want the script that called it to resume?

Based on Ray's examples, I would guess I will most often use Halt (anything initiating a new activity), and sometimes use Resume (anything just changing the current view, but not really the current context). I'll never use Pause and doubt I'll use Exit... unless someone has a good example of that for me.

Thanks for the help!

[harryk]

>In particular, Exit seems strange... unless its a button designed to be

>pressed specifically to exit that script.

Exit is not so strange. I use <exit script> a lot. For instance:

Show message[Print this layout?] OK/Cancel

If cancel

-exit script

endif

print[]

It is not quite a neat way of scripting, and you also could make the things to happen furtheron in the script an if-endif conditional to OK, but this is often more practical, and it works.

[smorr]

exit is also great from providing the functionality of a switch statement in scripts without getting into the ugliness of nested if/else statements

For example, create a script' Switch Usermode'

if [g_usermode = "Admin"]

Go to Layout [AdminLayout]

Exit Script

end if

if [g_usermode = "Standard"]

go to layout [standardLayout]

Exit Script

end if

#default case

Go to Layout [LimitedLayout]

Then in a separate script you simply call the switch

EG

Set Field [blah, "Blah Blah Blah"]

perform script [switch usermode]

show message ["Blah Blah Blah"]

Compare the above to the following in terms of readibility:

Set Field [blah, "Blah Blah Blah"]

if [g_usermode="admin"]

go to layout [Adminlayout]

else

if [g_usermode="Standard"]

go to layout [standardLayout]

else

#default case

Go to layout [LimitedLayout]

end if

end if

show message ["Blah Blah Blah"]

[kennedy]

Exit is not so strange. I use <exit script> a lot. For instance:

Show message[Print this layout?] OK/Cancel

If cancel

-exit script

endif

print[]

No, no... Exit Script in a script is perfectly understandable... far more common than Halt Script, I would expect. But that's not what we're talking about.

We're discussing the "X Current Script" option on the Perform Script call from a Button specification. You are given four choices of what to do with any current scripts when the button is pressed, prior to performing the specified script. It defaults to Pause. But it would seem that Halt and Resume are the only two that make much sense for most cases.

Brian

[smorr]

I also use the resume option on buttons often for simplifying interaction.

For example, In many of my solutions, I create two scripts

Script: [btn] Cancel

setfield [$result,"Cancel"]

and

Script: [btn] OK

setfield [$result,"OK"]

The buttons that call the script are set to resume after the button script finishes.

So now when I script interaction, I do something like this

Script: Get Users response

Allow User Abort [Off]

Go to layout [fakedialogbox]

setfield [$result,""]

pause/resume script[]

# After a user clicks the button, the script will resume here with the specified result

if [$result="OK"]

-- show Message ["You clicked OK"]

else

-- If [$result="Cancel"]

---- show Message ["You clicked Cancel"]

-- end if

end if

allow user abort [On]

The nice thing about this is that it ties the responses to a user interaction together the same script that initiates the user interaction and not in some independent button/script.

Also it makes the OK/Cancel/whatever button multipurpose -- you don't have to have an OK button for each specific user interaction.

Note the allow user abort is off. This is because if the user stops the script manually, the buttons will not have any effect because there is no script running to resume when the user clicks OK/Cancel.

[Aussie John]

"Show message[Print this layout?] OK/Cancel

If cancel"

How do you get the ok/cancel after the "print this layout? and cancel after if. I can only get a calculation.

Also OT I know but what use is the third button option in show message. Maybe answering the above will solve this query.

Thanks

[CobaltSky]

I'm afraid my colleagues were taking a few liberties with the syntax, no soubt for the sake of brevity.

First of all, the Show Message script step, when you click in the options panel to specify the message, displays a dialog with a large text area for the message, and then three single line text boxes for up to three button labels. Harryk tacked OK/Cancel onto the end of his script line to indicate the button text (even though that doesn't normally show in the ScriptMaker window).

As regards the If statement, you're quite correct that it presents a calculation dialog. To produce the code that Harry was alluding to with his "If cancel", you would need to specify the calculation formula as:

Status(CurrentMessageChoice) = 2

---

Which detects whether the user clicked the second button (ie the one labelled 'cancel') in the preceding dialog.

As to the third button, that depends entirely on your scripting needs. You can have up to three buttons, and you can call them whatever you like. The default is to have only two buttons, and the default text for those buttons is 'OK' and 'Cancel', but if you need to have buttons that say (for example) 'Now', 'Later' and 'Never' you simply enter the text. If you only want to have one button, you simply make sure that only one of the three button text fields has text in it.