Tips & Hints - Scripting

By Daniel Wood, 5 March 2012

tipshints1 weetbicks1


This is the third article in our series of tips and hints for FileMaker. This time we are focusing on scripts - from their creation, to editing and debugging. Take it as it is - this is just an assortment of our favorite time-savers, shortcuts, tips, hints, tricks, tools of the trade and more.

Getting to a Script for Editing

There are a number of different ways to access individual scripts or the Manage Scripts dialog.

Obviously the most common of these is via the Scripts menu, or using the shortcut cmd+shift+S (ctrl+shift+S on windows).

When in layout mode, one of the most common things done is creating buttons and attaching scripts to them:

tipshints1 39

From this dialog you can select the script via a modified - and modal - version of the Manage Scripts dialog.

tipshints1 40

While not initially obvious, you can in fact create and edit scripts from this dialog. In the normal Manage Scripts dialog a double click on a script will open it for editing. Here however the double click action is used to assign the script to the button.

To edit a script from this dialog, first select it and then choose Edit from the menu shown below.

tipshints1 41

When editing a script from this modal Manage Scripts dialog the script itself is also modal. You'll notice an OK and Cancel button provided on the script just like in versions of FileMaker prior to 10 (cmd+S to save and cmd+W to close are not available here).

Creating and editing scripts from this modal manage scripts dialog is a huge time saver when setting up a button as it saves you having to work your way back out of the chain of dialogs to get to the regular manage scripts dialog. If the script is simple enough then you may as well create it when you define the button :)

tipshints1 42

The script debugger in FileMaker Pro Advanced is another location where you may need to quickly access the script being debugged.

tipshints1 43

The middle button will open the script currently being debugged. This makes the debugger a useful tool for quickly opening a script attached to a button while in browse mode. Of course, the script you open cannot be saved while the script is still running in debugger, so be sure to halt the debugger in this situation.

Don't forget also that if editing scripts via the Manage Scripts dialog you can open more than one at a time. This is useful if you are dealing with a script that uses sub-scripts, or if you need to modify a large number of scripts at once. To do so, highlight the scripts you want to edit and then double-click - all chosen scripts will open.

tipshints1 44

Script folders are a great way to organize your scripts. If you are anything like me then you like to keep things tidy. Sometimes you'll have folders collapsed and others expanded, which can make locating a particular folder a real chore.

tipshints1 45

There is however a way to locate any folder whether it is expanded or collapsed by using the folder filter at the top of the Manage Scripts dialog.

tipshints1 46

Problem! While this filter does keep folders in the correct order, it does not nicely display the sub-levels of folders, and as a result all folders appear one beneath the other - you have no idea which is a sub-folder of another folder!

This can be remedied by adding spaces to the beginning of your folder names for each level. I'll admit it's not the nicest solution - this is something FileMaker should just do natively - but it can provide a nice effect for quick folder selection.

tipshints1 47

A Note on the Import Records script step

When it comes to creating copies of scripts, FileMaker gives you a few options. You can start with a blank script and copy script steps into it. You could duplicate the script or use the copy/paste script functionality. Finally, you can import scripts from other files.

All of these methods are fine methods but pay particular attention to the difference between the duplicate and copy/paste functionalities. Aside from the resulting copy's name change (a 2 on the end for copy/paste vs "copy" for duplicate) there is an interesting change that occurs in the Import Records script step.

In the picture below we have a straightforward import records script step that is importing contacts from another file into the current file.

tipshints1 48

tipshints1 49

Here we are using the matching names option as a means of providing the field mapping.

Now if we were to make a copy of this script using the copy/paste functionality we end up with:

tipshints1 50

as the mapping method on the import records step as opposed to using the duplicate command and having the step retain its mapping method:

tipshints1 51

In a situation where the import records script step is used in a script, the duplicate command is preferable to a straightforward copy/paste if you need to copy the script.

In fact, even copy/pasting that single script step to another script will revert the mapping to "last order". If the script is imported from another file, then the mapping is also changed.

Making writing a script easier

Here's a quick tip: when writing a script it is always a good idea to put yourself on a layout which is the main context the script will spend the majority of its time on. By doing so it means anytime you need to reference a field in a script step you can be sure that it will be in the initial list of fields to appear.

Chatty Scripts (mac only)

Sometimes we create scripts that can take quite a long time to execute. Examples of such might be doing a mass mail-out, or generating millions of test records. Other times we are debugging complex scripts that can take a long time to step through in the debugger to find out what's happening.

What do both of these scenarios have in common? Well, they both take a long time to do - time that busy developers do not have. What if there was a way to start a script running so you can basically forget about it, yet still debug it or be notified of its progress at the same time? There is a way on the mac.

tipshints1 63

The Speak [] script allows for a calculation to be presented to you in an auditory manner :) Better yet, it has an option to have the speech not impact on the scripts execution by pausing while talking.

There is some good potential for this script step to be used in debugging or progress notifications. Consider the script shown below:

tipshints1 64

Here we have a script that we will use to generate 100 million dummy records. We want to be kept abreast of how it is progressing, yet we don't wish to do this via custom dialogs that we have to manually dismiss, nor do we want to waste time defining variables to view in the data viewer (which suffers from update issues during script execution).

The Speak [] step is a great solution. We simply have the script tell us its progress. This is done every time a new 1 million records are created. The script step tells us how many records have been created. We could very easily tweak this to have it tell us what percentage of completion it is up to. Very cool! We can now fire up another copy of FileMaker Pro on the mac and do other work while leaving this to run in the background.

We first learn't of this cool technique from this article by the very talented Dwayne Wright at his FileMaker Thoughts blog - well worth checking out!

Secondary Action Modifiers

There are a number of script steps which require require two or more pieces of information for the step to be fully specified. In some cases it is possible to use a modifier key to open the secondary options.

As an example let's look at the Set Field script step.

tipshints1 58

The primary option is to specify the field as noted by the fact the button has focus. Double-clicking on the script step is going to run this first option. The secondary option of specifying the calculated result can be opened by using the option modifier key (alt on windows) and double-clicking on the script step. This is a huge time saver when writing scripts that use this step often.

Other script steps where a modifier key can be used to open the secondary options are:

  • Install OnTimer Script []
  • Set Selection []
  • Set Field []
  • Set Field By Name []
  • Set Next Serial Value []
  • Insert Text []
  • Insert Calculated Result []
  • Insert File []
  • Replace Field Contents []
  • Export Field Contents []
  • Save Records as Excel []
  • Save Records as PDF []

The import records script step cannot have its secondary option opened via modifier key, but it can be opened using the return/enter key which is still faster than using the specify button provided.

Adding Multiple Script Steps

Just in the same way we demonstrated how you can open multiple scripts at the same time, you can do the same with individual script steps. Quite often when writing a script you have a good idea of the steps you will require, so why not just add them all at the same time. You can go shopping for script steps, adding each step to your cart by selecting them from the list of steps. When you have chosen all of your steps, use the move button to checkout your steps to the script, or double click any of the selected steps.

tipshints1 59

Steps every script should have

There are some important script steps that it would be a good idea to add to most of your scripts prevent issues for your users.

The first is adding a script step to the very start of your script that determines the initial mode the script should be in. Typically this is going to be the Enter Browse Mode [] script step. Why you ask? Well consider a user who has gone into find mode to do a search, but in doing so they happen to click on a button that runs one of your scripts. That script is going to begin its execution in find mode - a new record command will be adding a new request, set field will be defining a find request, and so on.

You should always be explicit in defining context at the beginning of a script.

Lastly, putting an Exit Script[] step as the last step of your script is a very handy thing to do for debugging purposes. Without it you are unable to fully debug the very last script step.

tipshints1 60

Here is a very simple script to illustrate that last point. The script has a single set variable script step. Let's now debug this script to try and determine the value of $variable during execution:

tipshints1 61

Uh-oh! We are on the last script step, but our data viewer is still not showing the value of $variable. This is because $variable has not been defined yet. Because this is the last script step, once we move to the next step the script will end and $variable will be lost - we will never know what it could have been set to

tipshints1 62

What if we put an Exit Script [] step as the very last step? Now the Set Variable step is not the last in the script, and we have an opportunity to view its value. The script is going to exit anyway at the last step so the Exit Script [] step merely helps to serve as an extra debugging step for the "real" last step that precedes it.

Something to say? Post a comment...


  • Damian 25/04/2013 4:20am (11 years ago)

    I use Exit Script[] at the end of every script, you can use it to pass back the ID if you created a record or other values and also any error messages. For example a script that creates a new invoice could return the invoice ID if it works or various error messages (say 'This item already invoiced' or 'user doesnt have permission to create invoice') if the function failed to do what was expected you might need to know in whatever script called it in the first place.

  • Dimitris Valachis 07/03/2012 12:39pm (12 years ago)

    Thanks teamdf!

    Once again a great set of tips!

  • Donovan 07/03/2012 5:24am (12 years ago)

    Great post Daniel! There's several gems I'll be taking with me. I'd like to extend the list with a couple tips I didn't notice above. Sorry, windows users will need to make their own translations.

    1. When editing a script, there's often little need for using your mouse (at least on Mac OS). Just tab into the script step menu using Shift-Tab and use type-ahead to select your script step. Inject the step into your script using Enter or Ctl+Space.

    2. Use Ctl+Up/Down to move your script step within the script.

    3. Instead of double-clicking on a script step, use Ctl+Space. The option key works with that too! So you can just use your arrow to select a Set Field step, press Ctl+Opt+Space, and you're right in the calculation dialog.

    3. When stepping through a script in Script Debugger, you CAN save modifications to a script. It just can't be the active script. It's a great way to test subscripts; you can jump out of the subscript, modify it, then jump back in... repeat until fixed.


  • Jeffrey London 07/03/2012 4:08am (12 years ago)

    Thank you for this thoughtful discussion. There are so many things, when scripting, that I do not even consider - just habit. You have pointed out some short cuts as well as some innovative uses of script steps. I particularly like your use of:
    The Speak [] step, and modifier key to open the secondary options.

    I never had a reason for FileMaker to speak.

  • Daniel Wood 06/03/2012 9:32am (12 years ago)

    Cheers for that tip Lee, it's a good'un for sure, and something you weren't able to do in versions prior to 10 I believe, thanks!

    Jonathan I'm going to have to look into that evaluate feature because it sounds pretty powerful. I've used the developer assistant before but never that feature I believe, thanks for the heads up!

  • Jonathan Fletcher 06/03/2012 2:45am (12 years ago)

    Re., the opening a script while the debugger is running:

    You can make changes to the script while you are stepping through it by merely editing the script normally. The only thing you can't do is Save it. If you go to save it it will ask you if you want the stop the debugger.

    I frequently use with the excellent 2EmpowerFM Developer Assistant's "Evaluate" feature on an open script while it's running. You can look deep into the dark recesses of a calculation in a running script to see exactly what the calculation is doing in the live context. You can highlight all of, a sub-expression within, or just a field in, a calculation and truly debug on a micro-granular level. This one feature of this everybody-should-have-it tool has greatly increased my life expectancy.

  • Lee Hoong 05/03/2012 10:28pm (12 years ago)

    Excellent tips! I didn't know about the ability to add multiple script steps all at once - that's going to be a real time saver.

    Here's another tip (I believe it is Mac only):

    In the Edit script dialog, you can select and move multiple script steps and move them all at once. The selection does not have to be contiguous - use command-click for non-contiguous selections - and the steps end up in a contiguous block after the move.


RSS feed for comments on this page | RSS feed for all comments