Aborting scripts and script debugging?

[kennedy]

I was trying out a new set of scripts, when one of them tried to create a record without filling in both required fields. Up popped a dialog... and since this is mid-loop, many more such dialogs were to follow.

In that situation, how do you abort the script? It seemed no matter what I did, I couldn't make it stop. Allow User Abort is just for the script its called in, right? It doesn't carry over to sub-scripts, right? Any tips?

What I really wanted was for it to take me into ScriptMaker at the point where the script was at that moment. From there, it would be easy to fix. Does ScriptMaker come with any sort of debug capability? Profiling tools? Trace tools?

Since I haven't heard of any, I assume the answer is "no" to all.

How do you guys handle these tasks?

[LiveOak]

It is good practice to set error capture and user abort to the appropriate values in each script and subscript. If abort is on, you should be able to exit with multiple escapes or command periods. To control were you enter a script, I oftern use If (0) ... End If to prevent execution of parts of a script.

ScriptMaker does have debugger features. They are contained in the FileMaker Developer version.

-bd

[SteveB]

With scripts that have any complexity to them, set AllowUserAbort to 'on' so you can kill the script until you're sure. The debugger is helpful, but is incomplete because it won't show the values of variables. Before it was released, I used to insert show message steps that were wired to a 'debug' variable that I set at the top of the script.

Altho not a debugging technique per se, build your scripts as modular little subroutines and try to test these separately. I'll sometimes have scripts that will only have 6 statements.