Customized Deployment Options

FileMaker Pro Advanced allows you to perform a range of functions on a grouped set of files; youll find them in the Developer Utilities under the Tools menu. This function of FileMaker Pro Advanced focuses largely on modifying your files in preparation for specific types of deployment. These options vary from renaming files to building a kiosk. Review Figure 24.1 for an overview of the options available.

Figure 24.1. In the Developer Utilities dialog you e able to work with a group of files and apply various options or rename them.

The mechanics of the dialog are fairly simple: Add all the files in a given solution to the dialog (they need to be closed for you to do so) and then specify a destination project folder. FileMaker creates new files anytime you use these utilities, so it needs to know where to put them.

You can opt to save your Solution Utility settings. Often solutions require multiple Developer Utilities settings. By using the Load Settings and Save Settings buttons, youll be able to save yourself the trouble of having to reenter all the various settings. This is quite helpful: This dialog includes a number of options, and development and testing often requires running through the process multiple times.

Renaming Files

This might sound trivial, but don let the apparent simplicity here deceive you. Multifile solutions in FileMaker depend on filenames to maintain internal references. If you arbitrarily rename one of the files in a given solution via your operating system, FileMaker prompts you with a File could not be found error when it next tries to resolve a reference to that file. You risk breaking table occurrence references, script references, value list references, and more by renaming your files manually. We very strongly recommend against manually renaming files.

Tip

If you run across a file that shows signs of having been incorrectly renamed or lost altogether, the Database Design Report is a great place to turn to root out "file missing" problems.

To explore issues of file references in converting files from prior versions of FileMaker Pro, see "Fix File References," p. 548.

Rename your files by using the Developer Utilities dialog. Notice, as in Figure 24.2, that you will need to add all the files for a given solution to the dialog. This is important: You need to add both the file you want to rename and all those files that reference it. Then set new names for however many files you need to change. For example, suppose that you have a system composed of 10 linked files. Load all the files into the Developer Utilities dialog.

Figure 24.2. The files in this example have been prepared for renaming.

Rename just the one file you intend to rename. When you click Create, FileMaker generates new files in your destination project folder, leaving the old files unchanged. In the 10-file example, the one file would have its named changed, and all 10 files would have any references to that file updated to use the new name.

To learn how to manually address filename and reference problems, refer to "File Reference Errors" in the "Troubleshooting" section at the end of this chapter.

Solution Options

Using the Specify button under Solution Options, youll find a range of actions that FileMaker Pro Advanced can perform as it creates a new solution (and a new set of files). All these options generally pertain to readying your files for deployment; you would not necessarily use them during development, but rather at the end when you e preparing files for hand-off to users (see Figure 24.3).

Figure 24.3. Solution options enable you to prepare a set of files for deployment with options beyond simply posting to a server.

If youve used the Developer Utilities in previous versions of FileMaker (FileMaker Developer 7 and before), youll notice that three of the solution options are missing: Custom Scripts Menu Name, Custom Script for Help Menu Item, and Custom Script for About Menu Item. These features have been superseded by the new Custom Menus development feature in FileMaker Pro 8 Advanced.

Creating a Runtime Application

FileMaker Pro Advanced enables you to bind a set of files into a runtime applicationone that includes the FileMaker engine and does not require that the user buy a copy of FileMaker Pro to make use of the solution youve built. This is a great way to create distributable software with FileMaker Pro, and FileMaker, Inc.s licensing terms allow you to do so without further obligation.

Note

FileMaker Pro Advanceds licensing details for runtime solutions can be found in the Licensing PDF youll find in the root folder of your FileMaker Pro 8 Advanced installation.

Youll need to keep some conditions in mind. A bound runtime version does not support further development; a runtime solution does not include Layout mode, ScriptMaker, and the Define Database functions, thus disallowing further editing of the files. A runtime solution works only with the files bound with it; it may not be linked to other databases, either other runtimes or files hosted via FileMaker Server. Finally, a runtime solution is single-user only. If end users want to share the files, they need to turn to FileMaker Server and standard copies of FileMaker Pro.

Note

Its sometimes thought that a runtime file is necessarily read-only, but this isn the case. Assuming that the database user has the correct permissions, a runtime can be used to create, edit, and delete records just as with the regular FileMaker client. (The misconception may stem from the fact that bound files are often distributed on CD, and such files are indeed read-only until they e copied off the CD to a writable medium such as a hard drive.)

Lets look in more detail at the process of creating a runtime solution. As with any other use of the Developer Utilities, youll first need to choose the files you want to include in the bound solution, and load them into the Developer Utilities dialog window. Next, specify a project folder where the resulting solution files will be written (in their own directory).

Next youll need to click Specify under Solution Options, and then choose a series of binding options, as shown in Figure 24.4.

Figure 24.4. When creating a runtime solution, there are several options you must first set.

Heres a brief rundown on these options:

• Runtime Name The runtime name will be used to name the resulting solution directory, and it will also be the name of the master file created for the runtime (more details on the master file follow this list).
• Extension To distinguish the runtime files from regular FileMaker files (which in many senses they still are), the binding process adds a custom file extension to each of the solution files. You may choose your own extension; otherwise, a default extension of .USR will be applied.

  The extension for FileMaker-bound runtime solutions determines, in both Mac OS X and Windows, what application becomes associated with your individual solution fileswhich by definition is the runtime application you e in the process of creating. These file extensions simply help identify the application that should open your files and differentiate them from other FileMaker Pro documents.

  Mac OS X uses four-character extensions (creator codes), and FileMaker simply inserts an uppercase F after the first character (usr becomes uFsr). On Mac OS X, we recommend registering your creator code with Apple: http://developer.apple.com/dev/cftype/find.html.

  On Windows a somewhat incomplete check can be found directly via http://shell.windows.com/fileassoc/0409/xml/redir.asp?Ext=fp7 (where the last three letters are the extension you want to investigate). Another source of information can be found at http://filext.com/.

• Bindkey To have the runtime application recognize its associated files, the bind key in a given file needs to match the bind key of the application. This simple pairing ensures that a given application will authorize use of specific FileMaker Pro files. Notice in Figure 24.4 that FileMaker Advanced inserts a timestamp by default as a bind key.

  Tip

  To replace or add a file to a solution that has already been bound, use the same bind key when preparing that new file, and users will be able to drop the file in question directly into their solution folders. You need not replace the entire solution.

  
  

  Consider cases in which youd want to be able to add files to a solution to upgrade functionality or address bugs. This introduces the complex issue of upgrade paths in a FileMaker Pro solution. You need to remember that after someone begins using your solution, he will be adding and storing data in your files. If you were to simply replace those files with no concern for exporting or managing that data, users would open their applications and discover an empty shell waiting again for the first records to be created.

• Closing Splash Screen When users close your solution, they will see a small closing splash screen. You can determine how long the screen will be visible (212 seconds).
• Custom Image By default, the closing splash screen shows a FileMaker logo. You can instead include an image of your own for display on the closing splash screen. If you choose to include a custom closing image, size it for 382¥175 pixels at 72 dpi. JPEG and GIF both work best in cross-platform environments; we don recommend any other file type.

After youve chosen your solution options, you can click OK to start the process of creating the solution. The solution files are written into a directory with the same name as the runtime name you established previously. Its a common misconception about the runtime binding process that the result is one single, monolithic file. Try the process for yourself and youll see that this is not the case (remember, it creates a new set of solution files, so no need to worry about hurting your current files). Sample results for Mac OS X and Windows are shown in Figures 24.5 and 24.6. On the Mac youll get a fairly sparse file set, whereas with Windows youll get dozens of supporting DLLs. Don be surprised by the differences between the two platforms, and keep the following caution in mind.

Figure 24.5. A bound solution on the Mac OS results in a fairly small file set.

Figure 24.6. Binding a solution on Windows generates a rather large number of files.

Caution

Creating a bound runtime solution is a platform-specific process. A solution bound on the Mac OS cannot be used on Windows, and vice versa. The binding also needs to occur on the target platform. To create a bound solution for the Mac OS, youll need to run FileMaker Pro 8 Advanced on a Mac, and likewise for Windows. Its not possible to create both Mac and Windows runtimes in a single pass, from a single machine.

Regardless of platform, each bound solution contains a master file, of which youll want to take special note. The file has the name solution_name.extension, where solution_name is the solution name you chose when binding, and extension is the custom extension you chose. If you were creating a solution called Sales, and chose the default .USR extension, the master solution file would be called Sales.USR.

Besides the master file, there will also be a single additional file for each of the FileMaker files that went into the solution. Each will be named with your chosen file extension. So if your Sales solution was made up of files called Contact, Company, and Order, the bound solution would contain the following files: Sales.USR (the master file), Contact.USR, Company.USR, and Order.USR.

The master file is significant because this is the file that must be run in order to gain access to the solution. For example, if you were packaging the runtime onto a CD, the CD might contain your solution directory, but also a shortcut to the master file at the root level of the CD. Youd rather users not have to rummage around in a directory full of files to find the right one.

The individual database files (as opposed to the master file) are actually not much changed by the binding process. The database files within the application remain FileMaker Pro files, accessible from FileMaker Pro proper (assuming that you haven disabled such access via the Remove Admin Access solution option that is covered later in this section). You could continue to work with these files in FileMaker Pro or FileMaker Advanced, add features, and simply redeploy the altered files without having to re-create a runtime solution each and every time a change is called for. Likewise, you can have some users make use of the runtime applications and still others access separate copies of the files (or share files) with full versions of FileMaker Pro. Its rare that youd build a database that could be used in both single-user and multiuser modes, but the point here is that its possible.

Note that this somewhat mitigates the point that bound solutions are platform-specific. This is true of the solution as a whole, but the constituent database files remain for all intents and purposes FileMaker files, and can be edited as such on either platform.

Tip

Some bound runtime solutions require a good bit of data entry prior to their being ready to distribute to a wide audience. It can be convenient to host the filesjust as they areon FileMaker Server to allow multiple people to enter data. The fact that the FileMaker files themselves are unaltered by the binding process means you can swap them between a bound runtime application and FileMaker Pro or Server as needed.

Removing Admin Access

Removing admin access often goes hand-in-hand with creating a runtime solution, but it doesn necessarily have to. To prevent anyoneincluding yourselffrom changing the files in a given solution (regardless of whether you intend to bind them into a runtime), it is possible to remove all admin (or better, perhaps, "developer") access to a set of files.

Caution

Theres no going back after youve removed the accessso be certain you have all the kinks worked out of your solution, and keep your original files backed up!

Youll remove access to the dialogs for Define Database, Value Lists, File References, Accounts & Privileges, and Custom Functions. Access to Layout mode and ScriptMaker are also removed.

In addition, removing admin access removes any accounts set up explicitly with the [Full Access] privilege set. This is quite important because it actually modifies the account and privilege settings of your files. Your "developer" account will be removed. If you have written scripts that depend on a certain account being there, you need to be careful in how you accomplish such functions. You also need to ensure that you yourself have a password that will allow you into the solution after youve run this process.

Its possible to define an account and assign a custom privilege set that has the equivalent of full access without assigning it to the built-in [Full Access] set, but keep in mind that, again, the capability to use all editing functions will be removed from the files. Those menu options, regardless of the account you used to sign in, will be grayed out.

For a complete understanding of security in FileMaker, see Chapter 12, "Implementing Security," p. 325.

Tip

We recommend, at a minimum, making certain theres a good way to export all data from a solution before removing admin access. Just write a scripted routine that saves all records to XML files. This at least ensures that you can extract data from a locked-down version of your solution.

Developing Kiosk Solutions

Kiosks are good ways to present users with a completely encapsulated user experience. As an example, one of our favorite projects was building a kiosk-based wine recommendation service for grocery stores using touch-screen input.

Kiosk mode allows FileMaker Pro to open full-screen, with no toolbars or menus. On Windows and Mac OS X, the taskbar and Dock, respectively, become unavailable as well. This has the effect of taking over the entire computer environment and allowing you to build complete appliances that serve a specific purpose. If you combine kiosk mode with an alternative means of data inputtouch-screen input, bar-code readers, or other devicesthe result can be something that very much departs from what you might think of as a database.

Securing Kiosk Mode

Kiosk mode does not completely lock down a computer. On Windows, users can still use Alt+Tab to access different running processes. The way to avoid this is to simply establish FileMaker Pro as the only running application. Also, on Windows a Ctrl+Alt+Delete calls forward the Windows Task Manager, and the Windows key on current keyboards brings forward the Start menu. You need to take additional steps to lock down Windows.

If you plan on deploying many kiosks, this would be tedious, but you can use a system utility such as gpedit on Windows XP to lock access to various elements such as the Alt key and Start menu.

Another approach is to use a third-party utility such as Win Control: http://www.salfeld.com/software/wincontrol/index.html.

On Mac OS X, this is not as much an issue. Kiosk mode properly takes control of the computer environment, but there are still backdoors, not the least of which is simply pulling the power cable of the computer in question.

In general, though, keep in mind that kiosk mode is meant to facilitate a storefront experience especially geared toward touch-screen input, and it is not focused on delivering a specific level of security.

When preparing a solution for kiosk mode, you need to consider several unique issues, not the least of which are important user interface elements. Because FileMakers menus are inaccessible in kiosk mode, a vital requirement is to offer users a means for at least exiting the application. Without a scripted quit routine, users have to force-quit the application and may lose data as a result.

Being able to exit the application, though, is just the first requirement. Any function youd like users to be able to perform needs to have been scripted and attached to a layout object (such as a buttonFileMaker 8s new Custom Menus feature won help here). You can opt to leave the FileMaker Status Area open if you want, but none of FileMakers native keyboard shortcuts will work (for, say, creating or deleting records).

Most kiosks offer a complete set of scripted functions attached to a custom-crafted user interface, and very rarely do developers opt to leave the Status Area open. Therefore, you need to create scripts and buttons for navigating from layout to layout, for creating records, for managing any importing or exporting of data, and for dealing with upgrading the files themselves, if necessary.

After a kiosk is deployed to end users (it need not be a kioskit could just be a copy of a FileMaker database you e distributing widely), you leave the world of modifying and managing workgroup solutions and enter the world of commercial development, where your ability to tweak things becomes exponentially more difficult. This suggests that a solution needs to be completely tested and perfect before it goes out the dooror else you need to craft and implement an upgrade strategy that allows you to pass new functionality to your users without leaving them lost, with no means of preserving whatever data they may have input. This strategy could be as simple as exporting all data from the old version and importing into the new, or you could build a distributed file system in which its possible to replace certain files without altering the data itself.

For ideas on user interface approaches, see Chapter 13, "Advanced Interface Techniques," p. 353.

Polishing Your Custom Solution

When distributing a custom solution, you can better tailor its look and feel by creating a custom menu scheme that reflects and supports the identity of your application. In previous versions of FileMaker, you were limited to customizing the name of the Scripts menu, and to attaching your own scripts to the Help and About menu items. With FileMaker Pro 8 Advanced, you can implement a completely customized menu scheme. (Note that this will not be of any use in a solution destined for kiosk mode because kiosk mode removes menu access, as explained in the preceding section.)

A custom menu scheme allows you a very high degree of control over your solution: You could write a complete help system that might include opening a FileMaker Pro file or interface in itself. Users might then be able to perform find requests and employ other familiar approaches to using your system. The About menu could be as simple as a window with an image or a logo that is brought forward, or you could get as fancy as a QuickTime movie that is played within a container field.

For more information on custom menus, see "Working with Custom Menus," p. 373.

The opportunity FileMaker Pro Advanced gives you is to truly customize a solution so that it takes on an identity of its own.

Tip

This might seem a minor point, but weve found that if you take pains to give your solutions a name and add even simple levels of customization, end users will more easily accept the system that they will then presumably spend a good percentage of their work lives using.

Its also somewhat helpful in getting users and IT folks to differentiate FileMaker Prothe technologyfrom your specific solution. If you name and modestly customize it, you foster a better sense of differentiation by creating an identity other than "the FileMaker database."

Error Log

As Developer Utilities runs, it can keep track of any errors it encounters. To generate a log, simply turn on this option in the Solution Options. A text file named LogFile.txt is created in your solution folder. Some of the Developer Utilities processes run into errors that don prompt dialogs, and thus its a good idea to check the log before wrapping up a solution for end users.

These are the errors youll find in the log:

• Updating File Specs for this destination file skipped due to a previous fatal error.
• Destination file could not be created, and all further processing on it was skipped. File:
• Skipped runtime generation, due to missing or damaged resources.
• Destination folder could not be created, and all further processing was skipped. Folder name:

As you can see, these messages aren particularly illuminating and generally indicate that you have a significant problem with the interaction between your OS and FileMakers processes. In testing for these conditions, a full hard drive was the cause for some of these issues. If you see such messages, verify that its possible and practical to create a solution directory in the place youve chosen (meaning, check for a full disk, restrictive permissions, and the like), and verify that the source files open correctly and don appear corrupted.