Database Reference
In-Depth Information
No matter how you get it there, the breakpoint is indicated by a red arrow to the left of the
script step. To remove an existing breakpoint, just click it again (or select the line in the
Script Debugger and then click the Set/Clear Breakpoint button again). The arrow disap-
pears.
When you click the Run/Pause button, FileMaker runs to the
next
breakpoint it encounters
(even if it's in one of the subscripts this script calls). If you find you've hit a breakpoint be-
fore the one you want, just click Run/Pause again to jump to the next one. In fact, adding
breakpoints at key places in a complex script (and leaving them there) can make it easy to
quickly debug the script later, as you Run/Pause your way through the major chunks, stop-
ping to step through only the parts that currently interest you.
GEM IN THE ROUGH: CONDITIONAL BREAKPOINTS
Some programs have a feature called
conditional breakpoints
that let you tell the debugger to stop
on a certain line only when some condition is met. For example, you may want to stop only if the
$count variable is bigger than 100, or if the found count is more than 1000.
FileMaker doesn't have built-in conditional breakpoints, but you can easily set up a similar scheme.
Just add an If script step to your script that checks a meaningful condition. Then put a comment in-
side the If block and set a break point on the comment. FileMaker goes into the If block only when
the condition is met; otherwise it skips right past it and the breakpoint it contains.
For example, you might add this to a long loop in your script, so you can break only after the loop
has run 100 times:
If [$count > 100 ]
# break here
End If
If you set a breakpoint on the line with the “break here” comment, then you get the desired effect.
Examining Errors
Coping with errors can be a significant part of debugging a script. As you step through your
script line by line, the debugger constantly updates the Last Error display just below the list
of script steps (
Figure 13-3
). Normally this function shows 0 (zero) because most script steps
don't produce an error. But if you
do
encounter an error, the error number appears right after
the step runs, making it a breeze to see what error number a certain situation produced so you
can handle it in your code.
