To run a script using Script Debugger, choose Tools → Debug Scripts. It’s a toggle command, so a checkmark appears when the debugger’s on and disappears when it’s off. While the debugger’s on, FileMaker shows the Script Debugger window any time you run a script (Figure 19-1).

Figure 19-1. The Script Debugger window’s loaded with information about the current script. But even better, it gives you complete control over the script while it runs. You can run just one line of the script at a time, dig into subscripts or back out to the calling script, skip over some steps completely, back up and run some steps over again, or stop the script completely.

Unlike most dialog boxes, Script Debugger stays on top of your work while your script is running, giving you constant feedback. Because you often need to see what’s happening on your layout, you may find yourself moving the debugger window around on your screen so you can keep tabs on data that’s being created or edited, changing found sets and the context in which script steps are performed.

You may find that debugging is a whole lot easier on a desktop’s monitor, preferably one with a whole lot of screen real estate. Often, you need to see two or more FileMaker windows and Debugger at the same time. (Now that most laptop computers have higher resolutions, though, you may be able to arrange a laptop’s screen so that you can see at least one FileMaker window that’s unobscured by Debugger.) For instance, when you’re pushing or pulling data from one table to another (Section 15.5.6.3.3) you may need to see the layout for the source table as well as the target table, so you can see if the data’s moving into the proper fields. Or, if you’re using lots of Go to Related Record steps to create your found sets, one layout can show the parent records and another can show the child records. See the box on Section 19.3 for more debugger tips.

Debugger toolbar

The most important part of the debugger is its toolbar: Its nine buttons give you all the control you could ever want over running scripts. Unfortunately, the buttons don’t have names, so you have to either learn what each icon means, or spend a lot of time pointing at things and waiting for the little yellow tooltip to appear. For reference, Figure 19-2 shows the debugger’s tools.

Figure 19-2. With this picture, you get up-close and personal with the toolbar in the Script Debugger window. Each of these buttons is explained in more detail throughout this chapter. If you’ve ever used a debugger in another development environment, then you probably feel right at home.

Stepping through a script. The first three buttons on the debugger toolbar all have “step” in their names. When you first start a script with the debugger, it doesn’t start running. Instead, you see all the steps in the script, and the Current Position arrow (see Figure 19-1) points to the first step. This arrow always points to the next step that will run. If you just want to run that single step, click Step. The step runs, FileMaker moves the arrow to the next step in the list, and everything stops again, waiting for you to do something else. With this behavior in mind, you can easily step through the script line by line. You can see how your If and Loop steps work (by following the arrow), and you can watch things happen in your database windows while the script runs.

When the Current Position arrow points to a Perform Script step, the Step button runs the subscript as one unit. In other words, it run the whole subscript without stopping and then moves the arrow to the next line in this script. Click Step Into instead if you want to move into the subscript and step through it line by line. The last Step button is called Step Out. When you click this button, FileMaker finishes the current script, and returns you to the one that called it. Then you can step through that script line by line. If you click Step Out from a script that wasn’t called by another script, FileMaker just finishes the script and closes the debugger window.

Breakpoints. If clicking a button for each step starts to wear on you—say you’ve got a looping script with a whole slew of steps—you can use Run to Breakpoint instead. Often when you debug a script, you know the first several lines work fine, and you want to fast-forward to the part that seems to be broken. You can tell the debugger where to stop and pause—a breakpoint. Just select the line you want to get to, and click Set/Clear Breakpoint (you can also just click the gray bar to the left of the script step). FileMaker adds a breakpoint symbol by the step name. (To remove a breakpoint, click it or select the step and click Set/Clear Breakpoint again.)

Then click Run to Breakpoint. FileMaker abandons the line-by-line approach and starts running through the script normally; that is, as fast as it can. The script runs until it ends, or until it hits a breakpoint. Once the breakpoint is reached, the debugger switches back to line-by-line mode.

Note

When you click Run to Breakpoint, FileMaker stops at the first breakpoint it finds. If your script calls other scripts, and they have breakpoints, it may stop inside another script before it gets back to your breakpoint. If that happens, click Run to Breakpoint again to move to the next one.

Skipping and repeating. If you want to completely skip a step (or a series of steps), simply select the next step you want to run, and then click Set Next Step. FileMaker moves the Current Position arrow down to the new step, but doesn’t run any of the steps in between. You can also repeat steps you’ve already run by selecting a line higher up in the script before clicking Set Next Step. Either way, FileMaker stops at the new line so you can use the Step buttons to go line by line from there.

Stopping. If you get halfway through a script and then spot the problem, you can stop the script right away without stepping to the end. Just click Stop Execution and the debugger window disappears, leaving you wherever the script left off.

Once you’ve been debugging for a while, you may forget you have it on. To your chagrin, the debugger window pops up when you expect to see the script running. Don’t feel bad—it happens to professional developers all the time. Just click Stop Execution right away, turn off the debugger, and then run the script again. When the debugger first appears, nothing has happened yet, so it’s always safe to stop before you step. (If you have breakpoints set throughout your scripts, you can use Stop Execution rather than repeatedly clicking Run to Breakpoint to get to the end of the script.)

Editing. More often than not, you want to edit the script you’re debugging once you’ve found the problem. Normally you’d have to switch to the right file, open ScriptMaker, and then scroll to the right script. But the Go to ScriptMaker button can do all this for you. Click it, and FileMaker opens ScriptMaker with the right script already selected.

The Go to ScriptMaker button is useful even when you don’t necessarily need to debug. Suppose you have a button on a layout, and you want to edit the script it runs. Trouble is, you’re not exactly sure which script that is. The quickest way to find out—and get to the script—is to turn on the debugger, click the Go to ScriptMaker button, and then click ScriptMaker’s Edit button. You go directly to the script in just three clicks.

Active script(s) information

The bottom part of the window shows you detail about the active script—in other words, the script that’s running right now. It shows the name of the script, the file it lives in, and the value, if any, of the script parameter it had when it started.

But why’s this box so big if it just shows a few facts about one script? Because it can actually show a few bits about lots of scripts. Every time a script performs another script, it moves down in the list to make room for the new script’s information. FileMaker puts the top-most—and current—script in boldface at the top of the list. Below it, you see the script that came before. If that script was itself run by another script, that first script’s then third in the list. You can see how this looks in Figure 19-3.

Click on a script in the list to switch the debugger’s view to the new script. The Current Position arrow changes color (white with blue outline) to indicate that you’re viewing a script that doesn’t include the current script step.

Figure 19-3. When scripts call other scripts, FileMaker stacks the script names up in the ActiveScripts list. On top—and in bold lettering—you see the name of the script you’re currently looking at. Directly below each script is the name of the script that called it. If you have scripts calling scripts with more than four levels, you have to scroll the list to see the oldest ones.

Data Viewer

The last button on Script Debugger’s toolbar shows you the Data Viewer, a handy little window that lets you see the current values in script variables, fields, and calculations. You create a list of values that you want to keep an eye on—a watch list—and then use this box to see exactly what happens to them as you debug. Make heavy use of this little gem and you may find that you rarely need to switch layouts while Debugger’s running because you can monitor all your data through the Data Viewer. Before the viewer can show you any data, you have to tell it what to watch. Figure 19-4 shows you the Data Viewer window and its tools.

Figure 19-4. The Data Viewer has some standard buttons on its toolbar. The + sign lets you specify a new value to monitor, the double plus signs duplicate an existing one that you can edit, the pencil opens the dialog box for editing an expression, and the trash can lets you delete an expression from Data Viewer’s watch list.

When you open the Data Viewer for the first time, there’s nothing in its watch list yet. To add a watch item, click the + sign. In the window that opens, you tell FileMaker what fields and calculations you want to inspect. It works much like the Specify Calculation dialog box (Section 9.2), but with a few changes and a couple of extras:

• The Expression field is where you type your calculation.

• Click Evaluate Now to see a live evaluation of the calculation you’re building in the Result field.

• The “OK” button says Monitor instead. When you click it, the new item appears in the watch list’s Expressions column.

In all other respects, this dialog box works just like Specify Calculation. If you’re using Data Viewer in conjunction with Script Debugger, you want it to monitor the fields and variables in the script you’re troubleshooting. For example, if you wanted to troubleshoot the Create Invoice for Job script, you’d need to add its variables to the Data Viewer. The formula for watching a variable is just the variable’s name. Since variables aren’t tied to tables, they don’t appear in the Fields list, so you have to manually type in the names. But if you want to monitor a function, like Get ( ScriptParameter ), you pick it from the function list.

Items in your watch list may or may not show values when you tell Data Viewer to monitor them. Their behavior is determined by what you’re monitoring and when you add the item to the watch list. Here are some guidelines:

• Local script variables are usually blank when you first create them, since they’re set only when a script step runs.

• Global variables set by scripts may or may not have values in them when they’re created. You see a value if you run the script that sets a global variable after you open the file, but before you monitor the global variable. If you haven’t run a script that sets the global variable since the last time the file was closed, the value’s blank.

• Local and global variables set by calculations display their values upon creation.

• Functions that monitor continually evaluated processes (like Get ( Account-Name ) ) show their current value when you create them. These values don’t update unless you click the Refresh Values button, though.

• Field values, like Customers::Last Name, have values based on the record that’s active when you add the item to the watch list. Field values don’t update automatically when you scroll through records. Like functions, click Refresh Values to see the updated value.

Once you’ve added all the items you want to monitor to Data Viewer’s watch list, run your script with the debugger turned on. As a script steps sets a variable or runs a function, you see the updated value in the Value column. By watching your layouts, running Script Debugger, and monitoring Data Viewer, you’ve got plenty of help troubleshooting misbehaving scripts.

Warning

Anybody with FileMaker Pro Advanced can fire up Data Viewer and monitor the values in local and global variables, even if their privilege set doesn’t allow them to peek into certain fields or layouts. Using local variables doesn’t alleviate the security problem entirely, but it makes it a little harder for folks to peek at the data, since the script that sets a local variable has to be running in order to see the value in it.

Data Viewer isn’t attached to any particular file, so its watch list contents don’t change when you open and close files. The viewer can even be open while you have no databases open. Since all files and scripts share the same watch list, it can quickly get long and hard to monitor. Select items you aren’t using, then click the trash can icon to delete them.

You can also use Data Viewer to test a calculation before you define a field for it, or add it to a testing step in a script. Click the Evaluate Now button to see the calculation’s value, and then tweak the formula and reevaluate it until you get it working. Then just copy the formula and paste it into a field definition or script step.

GEM IN THE ROUGH : Unlooping the Loop

If you’re familiar with debuggers for other systems, you might have noticed that FileMaker’s debugger is missing a conditional breakpoint. In other words, you can’t set a breakpoint that stops the script sometimes but lets it continue other times.

If you have a long script that does a lot of looping, and you want to see what’s going wrong the 237th time through the loop, then you find yourself in debugger hell.

If you set a breakpoint in the loop, you have to click Run to Breakpoint 236 times to get where you want to start stepping. If you put it outside the loop, then FileMaker runs right past the problem and you don’t get a chance to see what’s happening.

To solve this problem, add an If step inside the loop with a comment inside. Make sure the comment is reached only when you want to stop, and then set a breakpoint on the comment itself, as pictured here. Now FileMaker runs through the loop until it gets right where you want, and only then does it find the breakpoint.

The Database Design Report window lets you tell FileMaker exactly what you want it to report on. You get to pick which files and table occurrences to include, what kinds of things you want to report on, and what format you want the report to use. You also get to decide whether you want to open the report right away, or just save it for later use. To get started, choose Tools → Database Design Report. Up pops the Database Design report dialog box (Figure 19-6).

Figure 19-6. Turn on “Automatically open report when done” if you want to see your Database Design Report right away. If you’re running this report because you want to look at it right now, turn this option on. Sometimes, though, you just run the report to have around in case you need it later. If that’s the case, turn this option off to save a few clicks.

The Available Files list in this window shows every open file. To include a file in the report, turn on the checkbox by its name. FileMaker assumes you want every file at first, so you may have to do more turning off than on.

In the DDR window, you tell FileMaker which files to examine by turning on their checkboxes. Select one in the list to see all its fields in the “Include fields from tables in selected file” list. Again, you can use the checkboxes in this list to tell FileMaker which tables you want included in the report.

In the “Include in Report” section, there’s a checkbox for each kind of database element the DDR can report on. Again, FileMaker assumes you want everything, but you’re free to limit the report to just certain information. The less you report on, the faster the report runs, and the smaller the final files.

Normally, FileMaker saves the report in HTML format so you can read and navigate it in any Web browser, but it also offers a more structured XML format. XML files aren’t easy for humans to read, but with the help of other software, you can process the XML and integrate information about your database into other systems. Furthermore, several companies make DDR analysis tools that process the XML version of your DDR and provide extra tools for browsing, finding, and reporting on the information it contains. (See the box on Section 19.3.3 for more information on these third-party tools.)

When you’re done making decisions, click Create. FileMaker asks you where to save the report. The DDR is made up of several files, so you probably want to make a new folder to hold the report. The more complex your files, the longer it takes to create the DDR. In a file with dozens of tables, each of which may have dozens or even hundreds of fields, this could take a minute or more. FileMaker displays a progress bar for you, so you can gauge how long the process will take.

If you checked “Automatically open report when done,” when you created the DDR, FileMaker launches your browser and shows you the DDR Report Overview (Figure 19-7) as soon as the progress bar disappears.

Figure 19-7. Report Overview is the first thing you see when you open a DDR is. It’s a table, with one row for every file you included in the report, and a column for each option you checked when you created the DDR. Each “cell” contains a link leading to more information. Each DDR lists the time/ and date of its creation, so you can tell if the report matches the current state of your database.

This file is the main report file, and it has URL links that bring up the detail pages. To view the DDR later, go to where you saved it and open the file called Summary, or Summary.html. (You also see a folder named for each file you selected when you created the DDR.)

On the overview page, the DDR tells you which elements you chose when you created the DDR. If you click a file name, you see the file detail page (Figure 19-8), with lots of information about that file. The links in each column go to the same file detail page, but each link scrolls you to the relevant section. On large databases, with lots of fields, this option can save you a lot of time scrolling through the page, looking for what you want. For instance, if you click the number in the Relationships column, you see the Relationships section of the file detail page.

Figure 19-8. When you click the File Name link on the Overview page, you see this page. The top link on the left leads back to the Overview page. All the others just scroll the page to various important parts. The report itself is also loaded with links. You can click any link to go to more details about that item.

Use the DDR to help you figure out what parts of your database can safely be edited or deleted. Since it’s so easy to create tables, fields, and layouts in FileMaker, you may well end up with extras that you don’t need when your database reaches completion. You can make your database easier to understand and more efficient by deleting these extra elements. But even if a database is the last word in efficiency, running a DDR is one of the best ways to trace the designer’s thinking process.

To see if—and how—a particular element is used, look at its detail. Suppose you have a bunch of fields you’d like to delete from your database, and you want to find out whether it’s safe to do so. First, click the Tables link—fields are part of tables. You see a list of tables, with information about how many fields each table contains, along with a list of occurrences of each table in the Relationship Graph (Figure 19-8). Click the link for a table’s fields, and you see a list of all the fields defined for that table.

Details appear in the Field Name, Type, and Options columns for every field. Comments, if there are any, show up in the Comments column. Any layouts or scripts that use the field are listed in the Layout and Script columns, respectively. You see the information in the Relationship column only if it’s a key field. Fields used in layouts, relationships, and scripts are called dependencies of those elements.

A DDR is also very useful if you’re upgrading a file from a previous version of FileMaker. You can figure out which elements of the old database are crucial and which ones you don’t have to bother recreating when you build your new database.

Suppose you’ve deleted a field, unaware that it’s a dependency for a script, as described in the previous section. Later, you run that script and notice an error, but you’re not sure what you did wrong. The DDR is the best way to track down the error—which is the first step in fixing it. Take, for example, the “-find unbilled activity” script you wrote back in Chapter 15 (Section 15.5.5). It searched in the Expenses::Job ID field for all unbilled expenses…but you’ve deleted the Job ID field.

If you examine that script in ScriptMaker, you can see the words “<Field Missing>” right in the script.

	Set Field [Expenses::<Field Missing>; "==" & Get (ScriptParameter)]

You might be able to find the error, but then again you might not, because the “<Field Missing>” error isn’t bold, or red, or highlighted in any way. And as great as Script Debugger is, it doesn’t lead you to the broken script step either. But a DDR can help you find all the trouble spots that arise from the deleted Expenses:: Job ID field.

To do this kind of sleuthing, search the DDR page for a character string, using your browser’s Find tool (pressing Ctrl+F or ⌘-F does the trick in most programs). Type the text you’re looking for in the Find field, then click Next (or whatever button your browser uses) to start the search. You see the first instance of your search criteria highlighted. Click the button again to find other instances.

The whole list of errors you might search for appears below. If you have any inkling what kind of error you’re looking for, start with that one:

Once you find a broken element, return to your database and fix it manually. The DDR won’t update itself to show your fix until you run another one. And since you can’t mark the electronic version of your DDR, a good way to keep track of your work is to print it out, then mark off each item as you fix it. Then, when all the broken elements are fixed (or you’ve deleted all the unused stuff), run another DDR. This time it should be clean, but if it’s not, you’ve got the tools to fix it.

Back on Section 17.3.2, you learned how to have FileMaker create tables and fields as you import data. But FileMaker Advanced is even cleverer. It lets you import tables and fields without the accompanying data, so you can copy the framework and fill in the information later. Start by choosing File → Define Database and clicking the Table tab. Click Import, and then locate the file that contains the table you want to copy.

You can even choose the current file, effectively copying an entire table or set of tables within the same file. Next, you tell FileMaker which specific tables to import in the dialog box shown in Figure 19-10.

Figure 19-10. You see a simple list of all tables in the source file you’ve chosen. Click all the tables you want to import. You don’t get to specify which fields are imported — they all come in. So if there are a few you don’t need, delete them when the import’s finished.

When FileMaker Advanced has finished importing the tables and fields, it displays a dialog box similar to the one you see when you import data (Section 17.3.1). You see a summary of how many tables and fields were created during the import.

If you have complex calculations that you want to reuse in another table within the same file, or in a different file, use the Copy and Paste buttons on the Fields tab in Define Database dialog box. Use the Shift key to select items next to each other in the field list. Use the ⌘key (Mac) or the Ctrl key (Windows) to select fields that aren’t next to each other in the list. When you’ve selected the fields you need, click Copy. Then open the table where you want to create the new fields, and finally click Paste to do the deed.

When you copy calculation fields, your results may vary depending on whether you also copy the field’s calculations reference (Section 9.2.1). It usually saves time to plan ahead and make sure the field references already exist in the target table before you copy and paste. But you can always paste the calculation fields and clean up the references later, especially if you intend to use different field names anyway. Here are some general rules:

You can use the Import button in the Define Scripts dialog box to import whole scripts from other files, but if you have FileMaker Advanced, you can avoid that cumbersome process. Simply open the file that contains the scripts you want to copy, then use the Copy and Paste buttons in the Define Scripts dialog box. Copy the scripts you want to reuse, then open the Define Scripts dialog box in the target file, and finally click Paste. Check all pasted scripts to see if any field, layout, or other reference needs to be pointed to another element in its new location. Copying or importing scripts works best when you need the whole script and all the elements referenced in your script were already in place, so that no script steps break on the way in.

You can also copy script steps individually or in chunks. In the Edit Script dialog box, select just the script steps you want, then click Copy. Then you either create a new script or open the script that needs your copied steps. Highlight the script step just above where you want the next steps to land, and then click Paste. Your recycled steps appear in your script. Fix any broken references as needed.

You don’t even have to move to a new script to find Copy and Paste useful. If you have a script in which a series of steps could be duplicated, and then edited so that they work slightly differently, just copy and paste them. Sure, you could use the Duplicate button, but then you have to move each step down into place one by one. With Copy and Paste, you get to place the new steps right where you want them.

All new files you create use FileMaker’s standard menu set unless you tell them to use a custom set. Just as each new file contains three default privilege sets, you get one set of custom menus that you can edit to suit your needs. And as with privilege sets, some items are in brackets and cannot be edited or duplicated, but you’re free to create new menus with the same name and customize them.

Your goal for this exercise in customizing menus is to remove menu items that might confuse your users. When people are just learning FileMaker, simplified menus are less intimidating than masses of unfamiliar commands. You can also help protect your database from damage by someone unwittingly choosing the wrong command. You start the process by editing the View menu so that only a few items show up.

By editing menus to suppress items that might confuse those who haven’t had indepth FileMaker training, you’ve made your database a friendlier place to work. But don’t stop there: In the next section, you’ll learn how to create menus that show lists of commands you do want people to see, like your scripts.

Using the steps described in the previous tutorial, you can edit FileMaker’s menus to your heart’s content, renaming them, and deleting extraneous commands to make room for new ones. If you don’t necessarily want to delete any existing menus or commands, or even if you do, you can always create additional menus from scratch.

So far, you’ve simplified one of FileMaker’s menus and created a custom menu from scratch. Now you need to get rid of a menu that strikes fear even in the hearts of experienced FileMaker users: You’re going to completely suppress the Windows menu.

At first glance through the Define Custom Menus dialog box, you might think that you just click an item in the Custom Menu list, and then click Delete to remove it. But you’ll run into problems if you do. First, if you highlight menus with brackets around their names, the Delete button is inactive. And if you select an item where the Delete button remains active (Help), and then delete it, you get a nasty surprise when you click OK and return to your file. You see the text “Missing Menu” inserted in the menu bar, and the Help menu stays right where it was. Despite these obstacles, you can remove an entire menu; you just have to dig a little deeper to do it.

As mentioned previously (Section 1.7.2.1), the Window menu can cause problems for new users. For example, the Show command lists files that they may not know are open. Hiding and showing windows is also perilous for new users if they don’t understand how FileMaker manages windows. Instead of bothering people with stuff they don’t need to know, you can just suppress this menu entirely by removing it from the menu bar.

Back in your database, the Window menu is gone entirely from the menu bar. This menu configuration is ideal for your data entry people, but not so great for administrative users, who understand the Window menu and use it all the time. Read on to find out how to tailor sets of menus for people with different privilege levels.

FileMaker Pro Advanced lets you create a set of custom menus (see Figure 19-13) and use it as the default for a file, meaning that everyone who uses your database sees it, every time. But since the people using your database may have different levels of skill (and trust), you may want your custom menus to adapt accordingly. In fact, if you’ve read this book’s chapters on layouts and privilege sets, you have all the tools you need to make the right menus appear to the right people at the right time. It’s a simple matter of assigning menu sets to these existing features. You can conceal certain menus and commands from people who don’t need them, but keep them available for everybody else. Or maybe you just want menu items to show up when they make sense for the active layout.

Figure 19-13. The field on the left lists the Custom Menus attached to the current set. Look in the list to see your edited View menu. The list on the right is a subset of the list on the left. Menus that aren’t in the right-hand list are not displayed when this custom menu set is active. The Move, Clear, and Clear All buttons are similar to the ones in the Sort dialog box.

Once you’ve created menu sets using the steps outlined earlier in this chapter, you can install them in any of several ways:

The most confusing thing about the developer utilities is that you have to close your files before you work with them—just the opposite of every other command in FileMaker. So close the files you want to modify, and then choose File → Developer Utilities. You behold the Developer Utilities dialog box (Figure 19-14).

Figure 19-14. The Developer Utilities window (File → Developer Utilities) lets you gather the files you want to change, and then tell FileMaker what changes to make. When you’re done, you click Create, and FileMaker builds new versions of your files (in a new location) with all the changes in place.

In the Developer Utilities window, you first choose which files you want to work with. Click Add to put a file on the list. In Mac OS X, you can select several files at once in the Open File dialog box using your Shift and ⌘ keystrokes. Alas, in Windows, you have to pick just one file, and then click Add again to add the next one. Keep on adding until every file you want to change is in the list. If you accidentally add the wrong file, select it and click Remove.

You have to pick one file to be your main file. This file is the one that opens first if you create a runtime solution, for example. To set the main file, just double-click it in the list. FileMaker shows a red square—it looks surprisingly like a script break-point—by the main file.

Create Runtime Solution application(s)

To create Runtime Solutions, add the files to the Solution Files list, and then select a project folder, just as you did above. Don’t type a new name for the Runtime in this window, though. Click the Specify button under Solution Options. You see the Specify Solution Options dialog box, as shown in Figure 19-15.

When you tell FileMaker you want to build a runtime solution, it generates a special program that you need to include with your databases. This program can do most of what FileMaker Pro can do, but it can’t modify tables, fields, layouts, or scripts. You get to decide what this program is called—just type it in the Runtime Name box. Along with the runtime program, FileMaker creates new copies of each of your files to go with it, and changes all the file name extensions to something other than .fp7. Tell FileMaker what extension to use in the Extension field.

Warning

Your computer’s operating system uses file name extensions to figure out which program files belong to. The Developer Utilities let you assign any extension you want, but you should avoid common extensions like .doc, .jpg, .mp3, and so on. You know computers—they get confused easily.

The new files don’t just have a new name; they are also modified internally so they’re bound to the runtime program, and the runtime program in turn can open only properly bound files. In other words, when you send people a runtime program, they can’t use it to open any old FileMaker Pro file.

Figure 19-15. The Specify Solution Options window lets you tell FileMaker what you want done to the files. Turn on a checkbox in the Options list to tell FileMaker you want that thing done to your files. Most options need to be configured, and when you select an item in the list, the bottom half of the window lets you change the appropriate settings.

To facilitate the binding process, FileMaker asks you to provide a bindkey. FileMaker stores this value in both the runtime program and any database files in the Developer Utilities window. The value you use for the bindkey is entirely unimportant, and there’s no need to keep it secret. But if you later want to bind new databases to the same runtime program, you’ll have to use the same bindkey.

Finally, when users exit the runtime program (in other words, when they close your database system), they see a “Made with FileMaker” splash screen. Normally, this screen looks like the one in Figure 19-16. You can also control how long the splash screen shows by putting the number of seconds in the Delay box. Unfortunately, you can’t make it go away entirely.

Remove admin access from files permanently

The “Remove admin access from files permanently” option doesn’t actually remove the accounts that have full access. Instead, it modifies the [Full Access] privilege set so that it no longer truly has full access. If you log in with an account that normally has full access, it doesn’t have access to the Define Database window, Layout mode, or ScriptMaker, and its access to Accounts & Privileges is limited to the Extended Privileges tab. This option has no settings.

Figure 19-16. When you quit a runtime solution, this window pops up for a few seconds. You can’t get rid of the “Made with FileMaker” logo, but you can change the big FileMaker graphic to anything you want. Just turn on “Custom image” and pick a picture file from your hard drive. FileMaker stretches the picture to fit in the window, so to avoid distortion, you should create a picture that is exactly 382 pixels wide and 175 pixels high.

Enable Kiosk mode for non-admin accounts

If you turn on Kiosk mode and then open the new file using an account that has full access, you don’t see any changes. But if you log in with a lesser account, everything changes. The screen goes completely black, except for the content area of your database window. You can see an example in Figure 19-17.

Figure 19-17. When you open a database in Kiosk mode (with an account that doesn’t have full access) it looks like this. Everything on the screen is completely black outside your layout. You can still switch layouts and otherwise interact with your database, but you can’t make new windows, resize the window, exit FileMaker, or switch to other programs. You also can’t print, enter Find mode, or otherwise use FileMaker’s features unless buttons on the layout let you.

When you use Kiosk mode, you typically hide the status area and let people control everything from buttons on layouts. Alternatively, you can use custom menus (Section 19.5.3) to hide all the menus and commands that would let nosy people poke around in your file. Remember to troubleshoot your file before creating a custom runtime from it, because any problems in your file (broken links, missing data, bad scripts) also show up in the runtime. But once you’ve suppressed all the normal FileMaker commands, folks have no way of getting around these problems.

If you build a runtime solution with FileMaker Advanced in Mac OS X, it runs only in Mac OS X. Likewise, if you build from Windows, your runtime solution is limited to Windows. If you need a runtime solution for both platforms, you must buy FileMaker Advanced for Mac OS X and for Windows and build a separate runtime solution on each kind of computer.