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 executed under what conditions? Should every script step always be executed? Should some be executed 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. Use the If script step and other Control script steps to perform script steps based on conditions you define, such as layout name.

•

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. Database solutions 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 moves forward.

•

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.

•

Which fields and layouts will the script need? Some steps require a field to be on the current layout (like the Go to Field script step, the Insert Text script step, and the Insert Calculated Result script step, while others, such as the Set Field script step and the Replace Field Contents script step, don't. Use the Go to Layout script step to switch to a layout that has the fields your script requires.

•

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 will you test your script? Use the Pause/Resume Script script step to pause at predefined points in your script. Save a clone of your database, and then define and test your script in it to preserve the original data. After testing the script, import data from the original file into the clone.

•

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 FileMaker Pro normally displays 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 managing privilege sets for more information.

•

How will users perform the script? You either need to 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 Manage Scripts dialog box or when a database is opened or closed. See Setting file options for information about running scripts when files are opened or closed.