It may be easier to have the script end instead of pause. Then the 'Done' button can perform the rest of the original script. The 'Cancel' button could just be a script that deletes or reverts, closes window or goes to another window
Hey thanks! Good idea!
I agree with Steve's suggestion but don't see potential trouble with using Halt Script. This is a commonly used method to halt all scripts currently paused in your solution. Before we had modal windows to open as dialogs with FileMaker 12, we frequently paused a script to emulate modal behavior for a new window opened for use as a dialog box and used Halt Script as part of the code to close that window.
Hi ... Thanks for the additional response ...
Certainly Halt Script would work just fine in my single user solution. But as I understand it, in a multi-user solution there might be other scripts paused, and Halt Script would stop them all with unpredictable results ... at least that's what I've read! I was looking for a best practice here ...
I'd like to see where you read that. To my Knowledge, in a multi-user system, a "halt script" by User A will halt all scripts paused in user A's session and have no effect on the paused scripts of other users.
The possible concern with Halt Script--as far as I know--is that it halts all of the current user's paused scripts and in some situations that can create unexpected results for the current user. But since pausing a script locks down a lot of user interface features or is a symptom of one script getting paused when it trips a script trigger, I find that those situations are both rare and something best avoided by designing your system to keep such instances of a paused script to an absolute minimum.
I read 'that' in the FM12 Developer Reference book, published by Que, authored by Bowers, Heady, Lane and Love. Page 355 in the description of the Halt Script step. I don't have a scanner, so here is a precis:
" .... Experienced developers generally avoid using this script step, especially when working in teams. It is common practice to call scripts from other scripts, and it can be difficult to predict what problems will occur if a given script stops not only its own execution, but also that of all other scripts. Best practice strongly recommends using the script step Exit Script and returning a result, perhaps and error number or True/False."
Also in FM13 The Missing Manual, published by O'Reilly, authored by Prosser and Gripman. Page 681 in the Note at the bottom of the page:
"Note: Halt Script has an even bigger downside. ... it is rarely a good idea to run another script that could halt before reaching its normal end. ... so use Halt Script sparingly."
Neither source alludes to multi-users. I can't find where I read that part!
I take your point in designing to avoid paused scripts altogether. What would you do to allow for data entry?
I don't think that you'll find any reference to Halt script affecting any user other than the current user. My last FMP 10 based system would have had all kinds of trouble if Halt script affected any other users and such did not occur even though many users were working with paused scripts and the use of Halt to cancel them.
While I agree that Exit Script is usually the better option, Halt script is there for a reason and if you need that "quit everything" result, then it is the correct step to use. (Knowing the reason behind such a "rule" allows you to intelligently ignore that rule when doing so provides a better solution.)
Why would allowing for data entry require pausing a script? Note Steve's method--which is one option that I also use though not the only one.