Some Script Steps are Better as Subscripts
Let’s go through the script section by section to see what’s in it.
- We’re expecting the parameter to be a JSON object so we test for valid JSON.
- Next we set local variables from the parameter and test that the single required value exists
- Next we test to see if the layout we’re on is in Table view. If it is we switch to Form view because Go To Object step will fail in Table view.
- Now we call the Go To Object step using $target for the Object Name, then get the error code from the step.
- If there was an error code other than 0 we create the error info that will be recorded in an error log.
- Finally we exit the script with a result that contains the error info.
The custom functions “ValidateScriptParam” and “ValidateRequiredValues” built the local variables containing error details that will be included in the custom function “#ScriptResult” if there were errors in the validation tests.
Doing one thing and doing it well
As you can see, except for some validation at the beginning of the script to make sure we have the minimum required values (1, in this example), the rest of the script is devoted to doing one thing and doing it really well – performing the Go To Object script step and making sure important error information is returned to the calling script.
Other script steps that we always run from inside scripts that are devoted to ensuring that the single step does it’s job well and builds error info if it doesn’t are:
- Refresh Object
- Refresh Portal Row
- Send Email
- Open Record
- Delete Record
- Delete Portal Row
I hope you found this helpful. If you need help taking your FileMaker solution to the next level with advanced error handling just drop us a line. We can provide tutoring so you can add the skills to your developer toolkit or, if you’d prefer, we can set up a system for you in an existing solution.
