FileMaker offers a couple of ways to field-hop—pressing Tab to move to the next field in order, or just clicking the desired field. It has script steps that mimic both techniques.

FileMaker has all the classic commands in its Edit menu: Undo, Cut, Copy, Paste, and Clear. It also has a script step for each of these commands. The Undo step is the simplest. It has no options at all, and has exactly the same effect as choosing Edit → Undo. It’s rare that you want to Undo something you just scripted, so you’ll rarely use this script step. It’s quite handy, though, if you use Custom Menus (Section 19.5.3) to control users’ access to certain menu commands because you need to provide scripts for everything your users might want to do.

Cut, Copy, and Clear are slightly more complicated, with two options each. The first, “Select entire contents” lets you decide which part of a field’s value gets copied and/or cleared. If you turn this option on, FileMaker selects the entire field before acting. If this option’s turned off, FileMaker copies whatever happens to be selected in the field. You also get a “Go to target field” option, through which the script can tell FileMaker which field to act on. If it’s not turned on, it uses the current field—the one the user’s in when the step runs.

The Paste step is the most complicated of these four. In addition to specifying which field you want, and whether or not to select everything in the field before pasting, you get an option to “Paste without style.” When you turn this option on, FileMaker pastes the text on the clipboard, but throws away any style information. If you’re in Windows, you get a fourth option: “Link if available.” If the data on the clipboard comes from a source that supports object linking, FileMaker embeds the linked object. Changes to the original data shows up in FileMaker. Turn this option off if you just want the script to paste a copy of the data.

FileMaker has two script steps to help you select text. The first, called Select All, selects everything in the current field, just like the Edit → Select All command. If you need more control, use Set Selection instead. This step has two options. First, you can specify a target field so that FileMaker operates on the current field. The step also has a separate Specify button (below the one associated with “Go to target field”) that brings up the Specify Set Selection window (Figure 14-1).

Figure 14-1. This window lets you tell FileMaker exactly what text you want the script to select. You can type numbers directly in the Start Position and End Position boxes, or click either Specify button to bring up the Specify Calculation dialog box.

If you imagine the text in your field as a string of letters, numbers, spaces, and punctuation, then you can pretend each of these is numbered. For instance, the word “Missing” has letters numbered one through seven. You first tell FileMaker where the selection should start by putting the number of the first character in the Start Position box. Next, you put the number of the last character in the End Position box. When the step runs, FileMaker selects these two characters and everything in between.

Editing field data is such an important part of FileMaker that there are more than 10 ways to put stuff in fields with a script step. On Section 13.1.4, you learned that the scripted process for creating a printed report could actually be shorter and more efficient than the manual process. Editing field data via scripts is also different from manually editing data, and the following sections cover those differences.

The first thing to understand is that most of these steps work only if the field is on the current layout. This property’s no problem for scripts you use to structure a user’s data entry, but it can be a roadblock in other cases. Suppose you have a script that sets a “Paid in Full” flag on an invoice. You want this script to work no matter what layout you’re on (as long as it’s one that shows Invoice records), and whether the field is on that layout or not. In that case, you need to understand the Set Field script step (Section 14.2.4.2).

	Last Name & ", Esquire"

Suppose you decide to add a Notes field to the Customer table in your database. You use this field to hold any arbitrary information you think is important about the customer. Unfortunately, you soon realize this field is a little too unorganized. You’ve no idea if the note that says, “Customer already paid” is from last Tuesday or last year. What you need is a consistent way to keep track of who left a note, and when. You decide everybody should record this information along with any note they leave. To make things even easier, you want to be sure people add new notesabove older notes. Thus, when a customer record has been around for a while, the Notes field would look something like this:

	--- 12/11/05 @ 3:30 PM by Summer ---
	Called the customer, confirmed order was received.

	--- 12/01/05 @ 1:25 PM by Stacey ---
	Customer called saying he never got his order. I checked and we have no
	record of shipment. I'm shipping again.

	--- 11/03/05 @ 4:58 PM by Dave ---
	Order came in really close to quittin' time. I'll deal with it later!

In this example, you create a script that “forces” all added comments into that format. This script adds a separator line with the date and time (plus a couple blank lines) and leaves the insertion point under the separator. You also create a button next to the Notes field that runs this script. All the user has to do is click and type.

Before you start creating your script, think about what you need to do in sequence. Here’s a breakdown:

Your next mission is to translate these plain-English steps into ScriptMaker steps, which you’ll do in the next section.

Lots of times, you want to be able to write scripts that work on multiple records. You might need to change values across a found set of records, or you might want to let FileMaker handle the serial numbering of all the records in a table. The next script steps let you manage data in lots of records without lots of hassle.

Perform Find/Replace

The Perform Find/Replace script step brings all the power of the Find/Replace command (Section 2.5.1) to your scripts. You can include the find parameters in the script step, or create a calculation to determine the parameters on the fly, as shown in Figure 14-3.

When you use this step, you pick which action you want to perform from the Perform pop-up menu. Your choices are Find Next, Replace and Find, Replace, and Replace All (these correspond with the buttons you use to dismiss the normal Find/Replace dialog box). The “Find what” and “Replace with” boxes each have a Specify button by them. If you know exactly what you’re looking for, you can type it right in these boxes. If you click Specify, you get to use a calculation to set these values instead.

For example, say your Notes field is such a smashing success, you find some customers have pages of notes—and it’s becoming a problem to find what you want.

You’d like a quick way to search the material in the Notes fields. Figure 14-4 shows one solution—add a button to the Customers layout that runs a Find script.

Figure 14-3. The window behind the Specify button on a Perform Find/Replace script step looks a lot like the normal Find/Replace window. But this version has a new pop-up menu (called Perform) and a couple new Specify buttons that let you specify calculated values for what you’re looking for and what you want to replace the found results with.

Figure 14-4. Here’s the Customers layout with a Notes field and a search field added. To find what you’re looking for, you can type something in the search field and click Find. On the following pages, you’ll write the script behind that Find button.

The script is simple. It just needs to go to the Notes field and use the Perform Find/Replace script step. You need a field to type the search value into, which you could create before opening ScriptMaker, but in real life you probably think of that after you start writing your script. FileMaker makes it easy to create fields without leaving the warmth and protection of ScriptMaker, as you’ll see in the following steps.

Here’s how to make the script. Call it Search Notes Field:

1. Add Go to Field as your first script step. Set it to go to the Customers::Notes field.

   First things first: You want to make sure the script searches the correct field. Now you create the Find script itself.

2. Add the Perform Find/Replace step to the script, and turn on the “Perform without dialog” option. Click the Specify button.

   You see the Perform Find/Replace Options window.

3. Make sure the Perform pop-up menu is set to Find Next, then click the Specify button to the right of the “Find what” box.

   The Specify Calculation window appears.

4. From the pop-up menu above the field list, choose Define Database .

   It makes sense for this field to use global storage, and since it doesn’t really belong to a customer, you add a new table for it as well. You can do that right here in the Define Database window.

   Note

   Scripts often make use of global fields, so FileMaker lets you create a quick table to hold them without cluttering or interfering with your relationship graph (Section 8.7.3).

5. Click the Tables tab and add a new table called Globals.

   This table holds global fields that aren’t tied to specific tables. You don’t need a relationship to a table in order to grab the value from a global field, so a table like this makes them very easy to find. If you’re working in the file you used back in Chapter 8, you may already have a table for your globals. If so, add your new global fields there.

6. Click the Fields tab, and select Globals from the Table pop-up menu. Add a new text field called Note Search Value and set it to use global storage. Click OK.

   You now have the only field your script needs. See Section 3.3.4.2 for more information on global storage fields.

7. Double-click the Globals::Note Search Value field to create its field reference as your calculation. Click OK.

   This calculation tells FileMaker where to look when it runs the Perform Find/Replace step—whatever’s in the new field, in this case. Clicking OK when you’re done returns you to the Perform Find/Replace Options window.

8. In the From the Direction pop-up menu, choose All .

   This options tells FileMaker to look through the entire Notes field.

9. Turn on the “Current record/request” and “Current field” radio buttons. Click OK until you’re back in your database.

   You don’t want the search to spill into different fields or records. These options restrict it to just the record the user’s viewing. Since the script first goes to the Notes field, FileMaker searches only that field.

To finish the job, add the new global field and a Find button to the Customers layout (as shown in Figure 14-4 on Section 14.2.6). Then type a value into the search field and click your script button to test your new script.

New Record/Request and Duplicate Record/Request have no options, and do exactly what you’d expect. The first script step creates a new record, just like the Records → New Record menu command. The second duplicates the current record. In either case, the new record becomes the current record, just like when you do it manually. You use these steps most often on buttons, when you’re taking away menu commands from people and providing them with buttons that only appear on the layouts where you want your users to be able to create records.

The Delete Record/Request script step deletes the current record. If you turn on its “Perform without dialog” option, the delete happens automatically with no warning. When this option is turned off, the user sees the same “Are you sure” message box he’d see when deleting a record manually.

There are two ways to change to a different record. You can move to it with the Go to Record/Request/Page script step, which works a lot like the Book icon in the status area. Or you can switch to a related record, or a set of related records, using the Go to Related Record script step.

Go to Related Record

You were first introduced to this power-step when learning about relationships (Section 8.1.3). It can go to a different record, found set, layout, window, and even file; all in one step. This step’s job is simple: It takes you to a related record. But carrying out that job isn’t so simple. When you click the Specify button, you get a wealth of choices, as shown in Figure 14-5. To go to a related record, you first need to tell FileMaker which related table occurrence you’re interested in, by selecting it from the “Get related record from” pop-up menu. For example, if you’re on the Customer layout and you want to see a related invoice, you should choose Invoices from the menu.

With this done, FileMaker can find the right record. But how should it show it to you? If you’re visiting related records, chances are you can’t view them directly on the current layout (since the layout is associated with the wrong table occurrence). So a Go to Related Record command almost always involves changing layouts. You pick the layout you want from the “Show record using layout” pop-up menu.

Figure 14-5. This window’s the same one you saw when you attached a Go to Related Record script step to a button back on Section 6.7.2 → But inside a script you wield a whole new level of power when you tie this command to other processes, like printing a report from a found set that changes based on whichever record a user’s on when running the script.

At first you might be surprised by the menu choices. It shows all the layouts associated with the table occurrence in the first pop-up menu, as you might expect. But it also shows layouts associated with any other occurrence of the same table. FileMaker uses the specified table occurrence to find the right related record, and the specified layout to show it to you. You can show an Invoice record from any layout that shows records from the Invoices table, no matter what occurrence it uses:

• If the table occurrence you picked in the first menu is an occurrence of a table from a different file, you can turn on “Use external table’s layout” to see layouts in the file the table comes from. When you use this option, FileMaker switches to a window for the other file instead of showing records in the current window.

• If you want a new window (whether you’re using an external table or not), turn on the “Show in new window” checkbox. When you do, you see the New Window Options dialog box, which is explained alongside the New Window script step on Section 14.6.

Finally, you get to decide how to deal with the found set when the script step finishes. See the box on Section 14.3.3.2 to help you decide when each option makes sense.

• If you don’t turn on “Show only related records,” FileMaker goes to the related table, but you see all the records in the related table, not just those that are children of the formerly active record. The first related record is active in your new found set. So, from the Customer layout, GTRR without “Show only related records” shows all your invoices, and the active record is the first one for the Customer that you’re viewing when the GTRR script step runs.

• If you turn on “Show only related records” and “Match current record only,” FileMaker returns a found set of only those records that match the active parent record. From the Customers Invoice, GTRR set as described above shows you a found set of just the Invoices for the Customer record that was active when the script step ran. The first related record would be the active one.

• Choosing “Show only related records” and “Match all records in current found set,” is most useful when you have a found set selected before the GTRR script step runs. In this scenario, FileMaker shows a new found set in which all the records are related to at least one of the records in the old found set. So, in the Customers layout, you’ve found your two highest volume customers. Use GTRR, matching all records in the current found set to find all the invoices related to either of these two customers. The first record that’s related to the Customer record that’s active when the GTRR script step runs is the active record in the new found set.

When you use your database in Browse mode, FileMaker does a lot of things automatically. When you start typing in a field, it locks the record. When you exit the record—click outside any field or press Enter—it commits the record. When you use a script, though, you’re not really clicking fields and pressing Enter. So how does FileMaker know when to lock a record and when to commit? You have to tell it, by including the appropriate script steps: Open Record/Request, Revert Record/Request, and Commit Record/Request.

Revert Record/Request

The Revert Record/Request step has only one option: “Perform without dialog.” When this option is turned off, the user sees the message in Figure 14-7. Otherwise, FileMaker reverts the record directly when the script runs.

Figure 14-6. If the layout is set not to save record changes (Section 4.4.3.1), and you don’t turn on the “Perform without dialog” checkbox you see this warning when the Commit Record/Request step runs. Click Save to commit the record. If you click Don’t Save, FileMaker reverts the record instead. The Cancel button leaves the record open and locked.

Figure 14-7. Unless you turn on the “Perform without dialog” option, your users see this dialog box when the Revert Record/Request step runs. If a user clicks Cancel, FileMaker leaves the record open and locked, which is probably not your intention.

These script steps are relatively easy to understand, but when to use them is hard to figure out. Here are some things to keep in mind when you’re trying to decide when you need to open or commit a record in a script:

• When you use a script step that inserts data into a field (and leaves the user in the field), then FileMaker locks the record when the step runs, but doesn’t commit the change. You can then do more work with fields if you want. FileMaker commits the record later, when the user exits the record.

• If your script changes to a different layout, switches to Find or Preview mode, or closes the window, FileMaker automatically commits the record if needed.

• If you use a script step that modifies several records—Replace Field Contents, for example—FileMaker locks, edits, and commits each record in turn, as it goes.

• If you perform a series of Set Field steps in a script, and you are not in the record when the script runs, FileMaker locks the record and makes the field changes. When the script is done, you’re not in the record (no field is active), but the record’s still locked and uncommitted. In other words, you can use the Records → Revert Record command to revert all the changes made by the script, which probably isn’t what you want to happen. Add a Commit Records/Requests script step at the end of the script to prevent the loss of data your script enters.

• If your script changes some records and includes a step to revert them if something goes wrong, you should probably make sure to commit any changes your user was making before your script changes anything. That way, the script doesn’t undo any of the user’s work. Thus, put a Commit Records/Requests step at the beginning of your script.

And if you’re still not sure if your script really needs an Open or Commit step, go ahead and open the record at the beginning of your script and commit it at the end. Sure it takes a nanosecond or two extra to run a couple of steps that might not strictly be needed. But what’s a nanosecond on the grand scale of time when your data may be at risk?

FREQUENTLY ASKED QUESTION: Why Open a Record?

Why would I ever use the Open Record/Request step? Doesn’t FileMaker automatically lock a record as soon as my script starts editing it?

For simple scripts, this step is almost always unnecessary. FileMaker does, indeed, just do the right thing. But as you’ll learn in Chapter 18, you can set your FileMaker database up so that multiple people can use it at the same time, each on her own computer. When you set FileMaker up this way, lots of interesting things can start happening.

For example, a record can change while you’re looking at it. Suppose a new area code is added in your area, and you write a script that looks at the phone number and decides, based on exchange code, whether or not to change the area code. The script might look like this:

	If [ "Exchange Code = 555 or Exchange Code
	= 377" ]
		Set Field [ Area Code, "602"]
	End If

You probably find this hard to believe, but technically, someone could change the Exchange Code field after the If step runs, but before the Set Field happens. (Remember that other people are editing records on other computers, so they’re free to make changes while the script is running on your computer.) If this scenario happens, you end up assigning the customer an incorrect phone number.

To fix this, you need to lock the record before you start looking at it:

	Open Record/Request
	If [ "Exchange Code = 555 or Exchange Code
	= 377" ]
		Set Field [ Area Code, "602"]
		Commit Record/Request [No Dialog]
	Else
		Revert Record/Request [No Dialog]
	End If

Now, somebody else can’t edit the Exchange Code field because the record is locked. In general, if your database has multiple users, you should open a record before you start looking at it in a script.

This script reverts the record when it didn’t make any changes. FileMaker does this reverting for two reasons. First, committing a record means saving the data, and that’s unnecessary here. Second, suppose a field has had validation turned on since this record was created. It’s possible that this unmodified record has now-invalid data. If you try to commit this data back, you get a validation error. Reverting avoids this error since nothing’s being saved. Moral of the story: Try to commit a record only when necessary.

FileMaker has two record-related script steps that do something you can’t easily do manually in Browse mode: Copy an entire record to the clipboard. One version copies just the current record, while the other copies every record in the found set at once.

Copy Record/Request

The first, called Copy Record/Request, copies data from every field on the layout and puts it on the clipboard. FileMaker puts a tab character between each field value.

If any field has more than one line, FileMaker converts the new line character into a funny character called a Vertical Tab. Some programs, like Microsoft Word, convert these characters back into new lines when you paste in a copied record. Figure 14-8 shows the result of pasting a Customer record into Microsoft Word.

Figure 14-8. The window in the back shows what it looks like when you copy a customer record, then paste it into a Word document. You see the first and last name twice because technically it appears on the layout twice (once in the header, and again in the editable fields). Although this block of text needs some serious cleanup, it’s often easier to copy/paste it all in one shot than to copy each field value individually. You can see a cleaned-up version in the front most window.

Note

Some programs don’t recognize vertical tab characters, so when you paste into them, you see boxes, vertical lines, or nothing at all. Your multi-line field values are strung together in one long line.

FileMaker has a script step specifically designed to go to a certain portal row. Why would you want to do that? First, when you use the Go to Field script step to target a field in a portal, it goes to the first portal row, which may not have anything to do with what the user needs at that point. If you want to put the user in the field on a different row, you need to go to that row first.

When you use data from a related field, or put data in a related field, and there are multiple related records, FileMaker grabs the value form the first record. If you want to tell FileMaker to work with a different related record instead, use a portal and go to the right row. See the box below for tips (and a warning) on working with portals.

The first, Perform Find, is the equivalent of a visit to Find mode, followed by a click of the Requests → Perform Find menu command. Perform Find’s single option lets you specify what find requests to use, but, surprisingly, you can skip it entirely. If you don’t turn this option on, then Perform Find assumes you’re already in Find mode with one or more requests, and works just like the Requests → Perform Find menu command (and the Find button in the status area). It looks for records that match the already defined find requests. All the matching records become the new found set.

But where do those find requests come from? Either the user creates them, or your script does. For example, many developers like to add special “Find” layouts to their databases. These layouts can show just the right fields, along with helpful text, to make things easier for the user. Figure 14-9 shows a Find layout for the Customers table.

Figure 14-9. This layout is designed specifically for Find mode. It shows people exactly what to do and provides nice big buttons to help them (the More button runs the New Record/Request step). Since this layout is for Find mode only, you need to make sure the user’s in Find mode when she comes here, and you need to take her to a different layout when she’s done. That calls for a script like the one shown in the next section.

The best way to deal with a layout like this is to add a “Find” button on your normal Customers layout. When the user clicks this button, it runs a script that goes to the Find layout and puts the user in Find mode. The script then pauses (see the box on Section 14.4.1), giving the user a chance to enter find requests. When she’s done, she clicks a button to Continue the script, which performs the find and switches back to the Customers layout.

To set this process up yourself, first create a Find Customers layout like the one shown in Figure 14-9. Then visit the Define Scripts window, click New, and name the script appropriately. Then follow these steps to define the script itself:

After you follow these steps, your completed Find Customer script should look like the one in Figure 14-10.

Figure 14-10. This is how your Find Customer script should look if you’ve been following the steps on Section 14.4. It first takes the user to the new Find Customers layout and switches to Find mode. Notice that the Enter Find Mode has its Pause option turned on—FileMaker automatically pauses the script after this step. When the user’s finished adding find requests and continues the script, FileMaker runs the Perform Find step (with no find requests specified, so it uses the ones the user created) and switches back to the Customers layout.

To complete your layout, you need the to put Find button on the Find Customers layout. Since the user’s always in the middle of a paused script when she sees this layout, you just need to wire this button to the Resume Script action.

With the script you created on the previous few pages, your users can search for just about anything they want, by entering find requests. More often than not, you don’t want to make users enter the find requests manually. After all, the whole point of a script is to have FileMaker do things so people don’t have to. If you know ahead of time exactly what you want the script to find, use the Perform Find step all by itself: Just turn on the “Specify find requests” option and put those requests right in the dialog box and the search options stay the same each time the script runs. When you specify find requests in a script, you see the window shown in Figure 14-12.

This window is pretty straightforward. To add a new find request, click New. To edit an existing request, select it first, and then click Edit (Figure 14-11). You can also delete or duplicate the selected step using the Delete and Duplicate buttons. Using the Specify Find Requests and Edit Find Request windows, you can tell the Perform Find step to do any find you can do from Find mode.

Figure 14-11. When you add a new find request or edit an existing one, you see this dialog box. It’s just a more structured way to type data in fields in Find mode. Instead of using your layouts, you use this window, which gives you direct access to every field in the database (the Fields List) and makes it easy to see exactly what fields are being used in the Criteria List.

To define a particular find request, you first select a field from the Field list (if it’s a repeating field, you can specify the repetition number in the Repetition box as well). Then you enter some text in the Criteria box. The Insert Symbol button gives you quick access to the same symbols you see in the status area in Find mode, and the Criteria box accepts all the standard symbols. Once you’ve finished entering the criteria, click Add to add it to the Criteria list.

Figure 14-12. The Specify Find Requests window shows up when you tell FileMaker you want the Perform Find script step to perform a predetermined find. (Developers call this technique hard coding.) Right now the window’s empty because nobody’s added any requests. On your screen, it might not be empty; FileMaker automatically fills it with all the requests you used the last time you were in Find mode. If you have requests, select them all and click Delete.

As dependable as static finds are, you may not always be able to predict what the user wants to find. Or the criteria for finding the same thing over and over can change, like when you’re searching in a date field. For example, suppose you want to find all the invoices created one week ago. You can easily do so in Find mode: Just put the date from a week ago in the Invoices::Date field. But what you put in that field changes every day. For example, if today’s November 7, and you create a script to find invoices from a week ago, you could attach this request to the Perform Find step:

	Invoices::Date = "10/31/2005"

Unfortunately, as soon as November 8 rolls around, this script won’t find week-old invoices. It always finds invoices from October 31, 2005. When you’re faced with a situation like this, you do have an option: Make the script build the find request the same way you would in Find mode. In other words, tell your script to go to Find mode, have it put the right date in the field, and then perform the find. You can use the Set Field script step to put the date in the Invoices::Date field since it conveniently lets you use a calculation to determine the actual date.

The script would look like the one in Figure 14-13.

Figure 14-13. This script builds the find request itself since it needs to use a calculation to determine the proper date to search for. Notice that the second step uses the calculation Get(CurrentDate) - 7 to determine the date one week ago. The Perform Find step has no requests specified, so FileMaker uses the one the script created. This kind of find script, which changes as your data changes, is called a dynamic find.

You may have already noticed that Perform Find doesn’t have an option for the Requests → Constrain Found Set and Requests → Extend Found Set commands. That’s because each of these is a separate script step. It makes sense really, because to Constrain or Extend a find, you have to have a find first. In other words, this process always takes two separate steps to complete.

The Extend Found Set and Constrain Found Set script step options work exactly like Perform Find. Everything you just learned about Perform Find still applies: You can hard-code the find requests, pause the script and let the user enter them, or build them in the script.

The Omit Record script step lives a dual life. If you’re in Browse mode when it runs, it simply omits the current record from the found set. If you’re in Find mode, on the other hand, it turns on the Omit checkbox in the status area.

The Omit Multiple Records only works in Browse mode and does the same thing as the Records → Omit Multiple command. As usual, you can specify the number of records to omit in the script, either as a number or calculation. You also get a “Perform without dialog” option so you can decide whether or not the user gets to enter the number of records to omit.

Finally, the Show Omitted Only script step has the same effect as the Records → Show Omitted menu command.

	New Record/Request
	Omit
	Set Field [Invoices::Date; "…" &
	Get(CurrentDate) - 365]

The simplest find-related script step is Modify Last Find. It has exactly the same effect as the Records → Modify Last Find command: It puts you in Find mode with the same requests you created the last time you were in Find mode.

Now that you’ve mastered the scripted find, you can keep right on going and automate the process of putting your found set to good use—outside of FileMaker. The Save/Send Records commands (covered in full in Chapter 17) let you export records into formats other programs can understand.

To make a new window on the screen, you use the New Window script step. With this step selected in your script, you see a Specify button in ScriptMaker’s Script Step Options area. Clicking this button brings up the New Window Options dialog box, pictured in Figure 14-14.

The first box—Window Name—gives your script control over the name of the window. (Window name is something you can control only from a script. When you create the window from the Window menu, FileMaker assigns it a name for you.) You can also tell FileMaker how big the window should be (Height and Width), and where to put the window on the screen (“Distance from top” and “Distance from left”).

Here are some tips on using the New Window Options dialog box:

Figure 14-14. The Window Options dialog box lets your script open and close windows and move them around the screen. You can use it to make family members think they have poltergeists in their PCs, or just make windows behave properly when your scripts run. See the box on Section 14.6.3 for advice.

In ScriptMaker parlance, you bring a window to the front by selecting it. As such, you use the Select Window script step. It has one option, which lets you specify a window by name, or select the current window, as shown in Figure 14-15. You also use the Select Window script step to show a hidden window and bring it to the front.

Figure 14-15. This is the window you see when you click the Specify button with a Select Window script step selected. From here, you can specify the Current Window, or choose Window Name and put the name of the window you want in the box. As usual, you can use a calculation to determine the window name as well.

The Close Window script step has the same options as Select Window. You tell FileMaker which window to close: the current window, or one you specify by name.

FileMaker has three ways to move and resize a window. You can opt for one of its canned window maneuvers or you can set the exact pixel size and location of the window just like you can with the New Window step. You can also hide the current window.

Move/Resize Window

For the ultimate in window control, call upon the Move/Resize Window script step. It can move and/or resize any window with pixel-perfect precision. Its Specify button shows the dialog box in Figure 14-16, where you can choose the window’s size and position. As with New Window, you can leave any of the size or position values empty. When you do, FileMaker leaves that part of the window’s size or position alone. For example, if you specify a new Width but leave Height blank, FileMaker makes the window wider or narrower, but its height doesn’t change.

Figure 14-16. The Move/Resize Window settings look like a combination of the Select Window settings and the New Window settings. First, you pick which window you want to work on (Current Window, or a window selected by name). You then specify the new size and position for the window.

Note

Move/Resize Window also selects the window it acts on, which always brings the window to the front, and, if it’s a hidden window, shows it.

FileMaker has a handful of other window-related script steps, listed below. They come in handy if you need to exert more control over what your users see. (Not to imply that you’re a control freak or anything.)

The Open File script step lets you open another FileMaker file. You can pick any of your previously defined file references (see Section 8.5.1) or define a new file reference if necessary. When the step runs, the specified file opens and appears in a new window. If the file has a script set to run when it opens, it runs.

If you want the file to open, but you don’t want to see a window on the screen, turn on the “Open hidden” option for this step. The file opens, but it’s listed in the Show Window submenu of the Window menu, with its name in parentheses.

The Close File script step closes an already open file. When you add the step, you get to pick any file reference or add a new one. You can also choose Current File to close the file the script is in. If the file is open when the script runs, all its windows close and its closing script runs.

If you have a database you don’t want to close, but you want to make a copy of it, you can do so with the Save a Copy As script step. It works just like the File → Save a Copy As command. You might want to script this command if you want to automatically back up several files at once without closing them.

The rest of the file-related script steps are almost never used…but that doesn’t mean you won’t find a good reason to use them.

You first saw the Open URL script step as a button command when learning about text calculations. When FileMaker runs this step, it asks the your computer’s operating system to open the URL you specify. Most often the URL is a web address (HTTP), but it can be any URL type your computer supports, including FTP, MAILTO, SSH, and even FMP7 (to open a file on a network server). As usual, you can specify the URL or let the user do it, and you can use a calculation if needed.

The Dial Phone script step tells your modem to dial the telephone using a phone number you provide. You can use a calculation to specify the phone number or enter it directly.

If you have an email program set up on your computer, FileMaker can use it to send email from a script. The Send Email script step has two options, the standard “Perform without dialog” checkbox and a Specify button. Clicking Specify shows the Send Mail Options window in Figure 14-17.

Figure 14-17. These are the settings for an outgoing email message. You get to tell FileMaker whom to send the message to (using To, CC, and BCC) and what the Subject and Body of the message should be. Finally, you can pick a single file to include as an attachment.

Although you probably wouldn’t guess it, you can use a calculation for each of the values in the Specify Mail dialog box. The little button to the right of each entry box shows a menu when clicked with two choices:

Whatever you specify for the To, CC, and BCC values, you can also select the associated “Get values from every record in found set” checkbox. When you turn any one of these boxes on, FileMaker creates one outgoing email message for each found record. Each message uses field data specific to one of the records. In this way, you can email all your customers in one shot, addressing each one individually, and including a custom-crafted email message for each.

The “Perform without dialog” option for this script step has an unexpected behavior. Instead of showing the user FileMaker’s Specify Mail dialog box when this option is turned off, FileMaker opens her email program, creates the message, and opens it onscreen. The user can then modify the message as needed and send it. If you turn “Perform without dialog” on, FileMaker puts the message directly in your email program’s outbox with no user interaction.

Any time changes are made to a record, FileMaker records those changes in your computer’s memory first, and writes the change to the hard drive later—when it gets some free time. If you want to force the changes to be written to disk immediately, you can run the Flush Cache to Disk script step. For instance, you might add this script step after a script that creates a new customer order. That way, if your computer crashes while you’re busily taking orders, you lose only the last one you were working on.

Last but not least, you can have a script exit or quit the FileMaker application on your behalf. Of course this causes every open window and file to be closed as well. People usually use this when they have just one database, and they never use FileMaker unless they’re in that database. They add the Exit Application step to the very end of their database’s closing script so that when they close the last database window FileMaker goes away too. (Of course you find FileMaker so useful you never want to close it, right?)