Many developers start every script with that. Their reasoning is that if a user presses esc or command period for some reason, the script is interrupted with an unpredictable part of the script left unperformed. In some cases, such an interruption can be catastrophic for the integrity of your database and could even "strand" the user on an unfamiliar layout lacking the controls to get back to where they started.
But in actual fact, most scripts are performed and completed so quickly that it is virtually impossible to interrupt them before they complete anyway.
The downside to using it is that you no longer are able, with FileMaker Pro, to interrupt a script that gets trapped in some kind of infinite loop short of force quitting and possibly damaging the database file. And with script triggers, you can get such a loop without any loop script step in your script... (With FileMaker Advanced, you can use the script debugger to halt such a runaway script.)
So you may not want to add this step until you are ready to release the database for use by others after having tested them to make sure that there are no such looping issues.
Thanks. I need it mainly for FMGo, it is pretty easy when connecting remotely to tap the screen by accident and be prompted to stop the script. I use FMP adv, so I can always use script debugger to fix a file if a script goes into an infinite loop. thanks for the tip.
Please note that in FMGO on an iPhone, a phone call can still interrupt your script...
I use FMP adv, so I can always use script debugger to fix a file if a script goes into an infinite loop. thanks for the tip.
Not if you are testing the DB on your iOS device when you get trapped in that loop.(If I had a dollar for every time a script that worked perfectly in development, failed to work correctly on the client's system...)