Tips & Hints - Scripting

Introduction

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:

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

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.

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 :)

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

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.

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.

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.

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.

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.

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:

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

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.

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:

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.

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.

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.

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:

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

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.