Those of you who own FileMaker Pro Developer have an added feature under your Scripts menu called “Script Debugger.” This is a vital tool for stepping through broken or “not quite right” scripts to see what’s happening with them and to fix them quickly. If you don’t own the Developer version of FileMaker, you still have debugging tricks available to you, but skip the following section, “Debugging Scripts with FileMaker Developer.”
Debugging Scripts with FileMaker Developer
If you own Developer:
What you see is that the “Relookup Prices Part 1” script has begun, but the script has paused just before executing step one of the script (turning user abort off). The point of the Script Debugger is that you can now step through the script step by step to make sure that it’s doing exactly what it’s supposed to.
Going from left to right at the top of the dialog, here’s what Script Debugger’s buttons do:
Step — Executes the currently highlighted script step and moves to the next one, pausing before execution.
Step Into — If the current step performs a subscript, this button goes to that subscript and pauses just before its first step. That subscript’s definition will now appear as the visible script and the Active Scripts box at the bottom of the dialog will update, showing that you are in a subscript of the current script (subscripts being listed beneath their parent script in the Active Scripts box).
Step Out — Executes the rest of the subscript you’ve been looking at and goes back to the next step in the parent script, pausing before executing it.
Run to Breakpoint — Runs all script steps, without pausing, until reaching a breakpoint or pause, which you can enter either in this dialog or in a script’s definition, if you’re using Developer. A breakpoint can be inserted by using the Set/Clear Breakpoint button in this dialog or by clicking in the gray area to the left of the script step in this dialog or in the script’s definition (there’s a gray area there, too). Breakpoints can be cleared from a script step by clicking the red breakpoint again.
Stop Execution — Stops running the script, leaving you in the database at whatever point the script happens to be in.
Set Next Step — Makes the currently highlighted script step (you can highlight a step by clicking it) the next step to be executed. Use this either to start executing and testing a script part way in, or to skip over some steps after you’ve already stepped through.
Set/Clear Breakpoint — Inserts a breakpoint next to the currently highlighted script step. If none are highlighted, no breakpoint is inserted.
Go to ScriptMaker — A handy tool to quickly jump to the current script (or subscript if you happened to be stepped into one) in ScriptMaker where you can then double-click the script to edit it.
You’ll find this very handy when you need to modify a script attached to a button in database systems with many, many scripts. Instead of opening ScriptMaker and scrolling down, down, down to find the script, simply turn on Debug Scripts, click the button, and you’ll see the script in the Script Debugger. Then just click the “Go to ScriptMaker” button and you’re there!
Try running this script a few more times while Debug Scripts is turned on. Try stepping out of subscripts, setting breakpoints, and setting next steps to run.
Debugging Scripts Without FileMaker Developer
Before FileMaker Developer, developers had to use regular old FileMaker to debug even quite complicated scripts. Some developers still use this method, and you might, too, if you don’t own FileMaker Developer.
Of course, if you don’t have access to Script Debugger, the debugging you have to do must be done in the script by using the Pause Script script step and perhaps the Beep and Show Message steps.
To start debugging a script that doesn’t seem to be working quite right, add a Pause or Halt in after its first step, then save and run it. If the database looks like it’s supposed to, edit the script again and move the Pause or Halt down one step and repeat. Using this method, you will eventually isolate the problem so that you can solve it.
This process can get a bit more complicated with a script that has many nested If statements or some loops. In such cases, you should use the Show Message or Show Custom Dialog script steps. You can create messages for each part of the If (“You’re in button choice 1” or “You made it through the inner loop”), letting you know which part of it you’re in, or letting you know each time you restart a loop. You could even use the “Show Custom Dialog” script step in conjunction with setting a global field (used in the custom dialog) while passing through a certain part of a script (“OK, you just replaced ‘Chris Kubica’ with ‘Clark Kent’ in record ‘3400’”).
FileMaker Pro 6 introduced the “Show Custom Dialog” script step, which does everything Show Message does and more. One of the useful features when debugging is that the dialog box can display the contents of a field. If you’re familiar with debugging environments for C or C++, you’ll quickly notice that Script Debugger (Developer only) doesn't have a feature for tracking the contents of fields through the running of a script. You can get around this by using Show Custom Dialog to display the contents of any field. (You might create a new calculation field for this purpose so that you can see the contents of multiple fields in a single dialog box.)
Leave User Abort Turned On During Development
While you should usually turn user abort off at the beginning of most scripts so users can’t abort a script early (which would threaten data integrity and possibly drop them into a layout or background database they should not have access to), it isn’t a good idea to turn user abort off while testing and creating scripts.
You see, if a script has a loop in it, for instance, and for some reason the user (or you!) get caught in an endless loop because the script was not debugged properly, there’s no way to get out of the loop except by force-quitting the FileMaker application. Of course, a forced quit could severely damage or completely destroy the structure and data in a database. Therefore, set “Allow User Abort” to off for a script (especially for scripts with Ifs and Loops in them) only after you’ve completely programmed and tested a given script, and only after you’ve made a backup of the database, just in case.
Another option is to have the Allow User Abort [Off] option only execute conditionally. When you’re working in “developer” mode, a global field is set. Then you can use script steps like this (a good candidate for a modular script):
Once you have done that, any time you’re working in “developer” mode, you either manually set or have a script set the gIsDeveloperMode field to 1 (interpreted by FileMaker as true) and you’ll always be able to abort a script when you need to.
Broken Scripts to Debug
We’ve included a few “broken” scripts at the end of the list of scripts in ScriptMaker in the ScriptMakerSteps.fp5 sample database, with script names like Broken Script #1. There are solutions to these problems as well, in accompanying scripts with names like “Broken Script #1 SOLVED”, in case you get stumped. The explanation of the solution is in the SOLVED script in a Comment script step.
File Maker Related Interview Questions
|Management Information systems Interview Questions||Software Engineering Interview Questions|
|File net Interview Questions||Data analyst Interview Questions|
|Hadoop Distributed File System (HDFS) Interview Questions||Linux File Systems Interview Questions|
|Excel Data Analysis Interview Questions||Asp Dot Net Database Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.