Automating tasks with scripts
Scripts can do simple tasks like setting print orientation, or complex tasks like preparing a customized mailing to each client.
For example, you could define a complex set of tasks that creates a thank you email to clients in your Clients database who have made purchases in the last week. The script composes an email tailored to each client. The script switches to Preview mode and pauses so you can see what the message looks like before it is sent. The whole task is initiated by clicking a button on the Sales Entry layout.
You build scripts by selecting from a list of FileMaker Pro commands, called script steps, specifying options (if necessary), and arranging the steps in the correct order to perform the task.
Scripts normally run on the client, but you may want to run some scripts on FileMaker Server or FileMaker Cloud to improve performance or to automatically run on a schedule. See About running scripts on FileMaker Server and FileMaker Cloud.
Planning a script
The more time you spend planning your script, the more likely that it will accomplish what you want. As you plan, ask yourself these questions:
- Can you separate the task into smaller tasks? You can define sub-scripts for each small task, and then define a script that performs the sub-scripts. It's easier to design and test several small scripts than one complex one. You can also reuse sub-scripts in other areas. (Use Perform Script script step to perform a sub-script inside another script.)
- What script steps should be run under what conditions? Should every script step always be run? Should some be run a number of times until a certain condition is met? Should the script call other scripts and sub-scripts? You can control the progression of the script in a number of different ways. See Control script steps for more information on creating scripts with conditional steps.
- Do you want the script to run in a particular layout? Because scripts are defined at the file level and can be called from any layout, you should make sure the script will operate in the layout or layouts you expect. Use the Go to Layout script step to change layouts.
- Should the script work on all records in the database, the current found set, or a specific set of records? (Use the Found Sets script steps to include only the records that you want to work with in the found set.)
- Is all the data you need in one database file, or will the script operate on more than one file? If you're using multiple files, which ones should the script open? In which file should the script(s) be defined? In most cases a script should be defined in the same file as the data it is processing. Custom apps with more than one file may need separate scripts in each file, depending on the complexity of the task you are trying to script.
- With which record should the script start? For example, when using the Loop script step, you must decide whether the loop starts at the first or last record, a specific record, or the current record in the found set. (Use the Go to Record/Request/Page script step, Go to Related Record script step, or Go to Portal Row script step to specify a starting record. If you don't include a navigation script step to determine the current record, the loop begins with the record that's current when the script is performed.)
- Which window do you want to use? A script is initially attached to a specific window, which may be in the background. The script remains on that window until a scripted action switches to another window. For example, use the Select Window script step to specify a different window. If the specified window is not available, the script switches to the foreground window of the file. When you pause a script, the associated window becomes the foreground window if it is available. See Windows script steps.
- Should the script switch among modes? A script can be run from Browse, Find, Layout, or Preview modes. Make sure your script is in the proper mode before it acts upon something. For example, use the Enter Browse Mode script step to modify data in fields and records, and use the Enter Find Mode script step to set up or perform a find request.
Note Scripts performed in Layout mode automatically switch to Browse mode before executing.
- Which fields and layouts will the script need? Some steps (such as the Go to Field script step and the Insert Text script step) require a field to be on the current layout, while others (such as the Set Field script step) don’t. Either use the Go to Layout script step to switch to a layout that has the fields your script requires, or place the fields on the gray area to the right of the layout to make the fields available for script steps but not to users.
- Should the records be processed in a certain order? Decide among the current sort order, a specified sort order, or unsorted (the order in which the records were created). Use the Sort Records script step or the Unsort Records script step before entering a loop to order your records properly before processing them.
- How should the script advance through multiple fields or records? (Use the Go to Record/Request/Page script step, the Loop script step, the Exit Loop If script step and the End Loop script step to control multiple field or record processing).
- When should the script finish? After all script steps have run? After a specified condition has been met? (Use the If script step, the Else If script step, and the Else script step to perform a task such as the Exit Script script step when the script reaches a specified condition.)
- Should users be able to stop the script while it is running? Does the script contain a process that could result in incomplete or incorrect data if the script finishes too soon? Use the Allow User Abort script step to control if users can stop a script.
- How will you test your script? Use the Pause/Resume Script script step to pause at predefined points in your script. Save a copy of your database, and then define and test your script in it to preserve the original data.
Note You can use the Script Debugger to test and troubleshoot your scripts. See Debugging scripts.
- How will you handle error conditions (such as an empty found set)? You can capture the last error condition reported by FileMaker Pro by using the Get(LastError) function. Use this function and the If script step, the Else If script step, and the Else script step to create scripts that react gracefully to user errors or unexpected results. For even greater control, use the Set Error Capture script step to suppress the error alerts that are normally displayed in these situations, and replace them with your own using the Show Custom Dialog script step.
- Should all users be allowed to perform all scripts? Use privilege sets to control users’ access to scripting. Through the use of privilege sets, users can be allowed to execute or modify individual scripts, no scripts, or all scripts. You can also set the default permission for each privileges set for any future new scripts that are defined in the file. Setting a script to run with full access privileges will allow the script to do things on behalf of the user that may not be normally allowed by their assigned privileges. See Creating and editing privilege sets.
- How will users perform the script? You need to either create a button to perform the script or specify that the script be added to the Scripts menu. Scripts can also be run from the Script Workspace or when a script trigger is activated. For example, you can use the OnFirstWindowOpen script trigger to run a script when the database opens.
Once you've considered these questions, you're ready to manage scripts in your database. See Creating and editing scripts.