That's a tough one as the user abort can terminate the script anywhere within your script.
You could, I suppose, set a global variable with a value when the script starts, then change the value as the last script step. Your "check for abort" script could then examine the value of this variable to determine whether or not the script was allowed to run to completion.
That's one thing I had considered already, and it would certainly accommodate my needs. The problem is: How do I trigger the "check for abort" script?
Yep, that is indeed the problem as there is no such script trigger. You'd have to link that check to other user activities that do trigger scripts.
Can you explain your situation in detail? That might enable me to suggest a way to trigger that script or a completely different approach that eliminates the need to check for such a user action.
I'm iterating over records in list view, doing various things. For instance, a directory path from a field of each record is read, and some stuff is done in a shell with each of them, like counting the number of files in a subfolder of the path, etc. In the end, statistics are shown in a dialog box (total number of found files etc.). Now, since I have hundreds of thousands of records in that table, this process can take hours. I utterly need to let the user know about the progress, with an estimate of the remaining time. I do this with a non-modal progress bar dialog from the "Dialog Plugin", which is the best free solution I know. I had implemented a progress bar directly in the FileMaker layout, using repeating fields, but periodically refreshing the progress bar (and thus the layout) was just too slow, because each record is showing tons of data like images and more. Hence the non-modal dialog, which is a much nicer/faster solution in my case. Unfortunately, the mentioned plugin doesn't offer an "Abort" button or any other way of letting the user indicate that he'd like to abort the process (which he will want to, because, for instance, he figured he'd not want to wait for three more hours) -- that's why I don't set "Allow User Abort [Off]" in the script. Ok. So, when the user actually does abort the script, the non-modal dialog is left open, because the terminal "hide progress bar dialog" script step is never reached. I'd really like to close it upon user abort.
Perhaps there's a better way of enabling some sort of user feedback during the process (other than having to "Allow User Abort [On]"). An abort button on the FileMaker layout doesn't seem to work, as it can't be clicked, because the mouse pointer is the ⌘ symbol (Mac OS X) while the sript is running.
One method another user and I kicked around was adding periodic checks to see if a specific modifier key was down to intrerrupt a running script. By using an unusual key combination, the script could use Get ( ModifierKeys ) and halt or exit the script if they were down. This approach would allow you to then make a graceful exit closing dialogs/windows etc.
Note that FileMaker can detect such keydowns even when running in the background and the user is using a different application so don't use something simple like detecting the shift or ctrl key if that's a possible user scenario here.
Another option (which you likely have already done) is to evaluate ways to change the design of your tables/data to eliminate or simplify the amount of such data processing needed.
"periodically refreshing the progress bar (and thus the layout) was just too slow, because each record is showing tons of data"
Perhaps you could make that approach work for you by creating a layout based on the same table occurrence but which is actually blank or greatly simplified. After the script completes, the script can return the user to the original layout.
The Get ( ActiveModifierKeys ) solution is close to perfect, I've implemented it, and it works nicely. PhilModJunk, thank you so much for your help and suggestions!