Allow User Abort

Managing ‘User Abort’ in Scripts
The Allow User Abort script step is used to prevent users from stopping a script. One reason this may be necessary is when a script takes the user to an unfamiliar location. If the user aborts the script, they may not be able to get back to where they started.
By default, user abort is on. If a user clicks Cancel on a print dialog during a script, FileMaker Pro will inform the user that print has been cancelled and give them the option of continuing or canceling the script.

The problem is that many users don’t know what a script is (or that they were running one!), don’t know if they should continue, and therefore click Cancel. This stops the script dead and often leaves them in a foreign location in the database.

One solution to this problem is to insert a script step Allow User Abort and set the option to Off. With this step before the Print step that displays a Print dialog, FileMaker Pro does not ask the question when the user clicks Cancel - the script always continues. There are many other places where the user’s ability to cancel the script is stopped.

But as a developer you should also be aware that it prevents every user (even you) from stopping a script (unless you are running the Script Debugger in FileMaker Pro Advanced). This can be disastrous if an untested script enters an infinite loop or if you want to stop a process that you know is going to take a while.

So what this usually means is that you will put an Allow User Abort step in a script where you need it but set the option to ‘On’ while you are testing. When you are satisfied that there are no infinite loops or other serious bugs, you reset the option to ‘Off’.

Do you see the problem here? At some stage, you need to change all the Allow User Abort script steps in all your scripts to ‘On’. How many scripts is that? And how do you know you got them all? And what do you do when you need to turn them all off again for further testing?

Here is a simple solution - use a subscript instead of a script step. Confused? I will explain.

1. Create a one step script called Allow User Abort On. The one step is Allow User Abort with the option set to ‘On’.

2. In any script where you need to control User Abort, ‘call’ the script with the Perform Script step.

3. Test what you need to test.

4. To turn User Abort Off in your solution, open the script, change the name to Allow User Abort Off and reset the script step option to ‘Off’.

5. To turn User Abort On again in your solution, open the script, change the name to Allow User Abort On and reset the script step option to ‘On’.
6. Rinse and repeat as needed.

The point about always updating the script name to reflect the state of the User Abort step is that it makes sense when you read scripts that call it:

Now, more advanced users may be thinking - “Can we make that subscript more dynamic? I keep forgetting to change the name or the option”.

Well I’m glad you’re thinking! Of course we can. Try this script instead - it uses the last word in the script name to determine if User Abort is on or off. All you need to do is to rename the script to alternate between states.

So what we have now is a method to turn user abort on or off in our database in just one location. Master control!