Script Steps As Scripts

Script showing "Think outside the box" as a graphic in it

Some Script Steps are Better as Subscripts

Imagine you have a FileMaker solution that uses the script step “Go To Object” at least once in 30 different scripts. That’s at least 30 different places you’re testing for the error code after that step. If you’re composing meaningful error information that’s discussed in the blog post To Err Is Human, Smart Error Handling Is Divine, then you’re collecting the same basic error info over and over in a new Set Variable step each time.

That’s a lot of work. And you better hope you never have to maintain all those disparate lines of code if you come up with a different way of handling errors.

Fortunately there’s an easy way to address all the problems associated with this approach; create a script whose only purpose is to call the “Go To Object” step and handle all errors that occur from calling the step.

The following is an example of the Go To Object script we use (click/tap to enlarge).

Let’s go through the script section by section to see what’s in it.

  1. We’re expecting the parameter to be a JSON object so we test for valid JSON.
  2. Next we set local variables from the parameter and test that the single required value exists
  3. 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.
  4. Now we call the Go To Object step using $target for the Object Name, then get the error code from the step.
  5. If there was an error code other than 0 we create the error info that will be recorded in an error log.
  6. 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.

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

Leave a Reply

Your email address will not be published. Required fields are marked *

More To Explore

Frustrated software user
Developer Skills

Problem Users Make Us Better Developers

Ask any seasoned app developer if they have a “problem user” story and the reply usually begins with something like, “You would not believe what

FileMaker 18 Certified Developer Certification
FileMaker Certification

The Road to FileMaker 18 Certification

Time was running out The email from Claris made it clear. If I was going to get my FileMaker 18 Certification I better do it

Traffic lights used to represent stop and go conditions
FileMaker Techniques

Using Hidden State For Validation

Hiding a button to provide feedback Do you ever use FileMaker’s layout object’s “Hide object when” behavior to hide a button until some criteria have

Want more satisfaction, less stress?

Talk to us, We May be exactly what you need

Satisfied Office Manager with less stress
small_c_popup.png

We'd love to hear from you