by Marie P. Folker, <editor@filemakermagazine.com>, http://www.filemakermagazine.com
Binding Revisited
PLATFORM: Mac/Win
Making Runtime Versions of your FileMaker Pro solutions has never been easier. In order to examine how this process has changed, I thought a tour through a binding routine was in order. Unfortunately because the runtime engine for FileMaker Pro is in the vicinity of 2 megs, it made little sense to include it as a bonus file. It won't make much difference to us though; you will need to purchase the new Developer Edition of FileMaker Pro to follow along anyway. In case you don't have it, I'll be as descriptive as possible.
What is Binding?
The process of generating a runtime version of the FileMaker Pro application that is tied to your solution files is called binding. In order to bind a solution, you will need to:
1. Specify the solution's primary file.
2. Name the runtime application.
3. Assign a binding key.
4. Add any auxiliary files to the runtime solution.
5. Choose additional binding options, such as Kiosk mode.
6. Assign the solution's three-character extension to the solution files.
7. Specify the folder where the runtime application and solution files will be placed.
We'll discuss these steps in more detail as we go through the process.
The Binding Utility
The binding utility itself is a five-panel, assistant-type application that nicely guides you through all of the required steps for creating a runtime solution. In the first panel we'll set the primary file, the solution name, and the binding key.
The Primary File
There is only one primary file in a bound FileMaker solution. This file is opened first if there are auxiliary files. The primary file isn't any different then a traditional "Main" file in most multi-file solutions. It is common that the primary file is mearly a navigational file that interacts with the auxiliary (related) files that make up the entire solution.
To set the primary file, you simply click on the Select button and choose the primary file from the open dialog. A nice shortcut is to simply drag your primary file onto the Binder utility or into the first dialog of the running Binder utility. Once the primary file has been specified, you'll notice that the solution has been named the same name as the primary file with the word "Solution" following it. You can change this to anything you like as long as the name follows that platform naming conventions as follows:
Mac OS 31 characters
Windows 95 255 characters, including path
Windows NT 255 characters, including path
Windows 3.1 8 characters plus 3-character filename extension
There is also a small list of forbidden characters listed in the Developer's guide.
The Binding Key
The binding key links the runtime engine to your solution files much like a 3-character extension works under Windows 3.1 or the type and creator code on Mac OS. This binding key is stored in the background and is set in the first window of the Binding utility. The key defaults to "123456" and is required to be between 6 and 31 characters. The key is case sensitive on Mac OS. It is important to remember the binding key so that later modifications of the solution can be performed without rebinding the entire solution. When you are creating a cross-platform solution, you should use the same binding key for both.
Auxiliary Files
The next panel provides the capability of adding auxiliary files. An auxiliary files are simply the rest of the files in your solution other than the primary file specified before. While you can bind a solution with more than 50 files, remember that the runtime application can only run 50 files at one time just like the standalone version of FileMaker Pro. To add auxiliary files, simply click on the "Add" button and choose the files from the open dialog. If you need to add several files, you can drag multiple files on the second dialog of the Binder, a great time saver.
Binding Options
There are several new binding options available in the latest version of the Binder. Here is the list of current binding options:
• Run solution in Kiosk mode
• Permanently remove access to Define Fields, Define Relationships, ScriptMaker, and Access Privileges
• Disable runtime solution closing screen
• Use custom About script
• Use custom Help script
• Rename Script Menu
Those new to the Binder may not be aware of Kiosk mode. This is an ingenuous idea that has been carried through to this latest version. What it does is suppress the interface of the operating system of the computer running the solution. Not only are the operating system elements suppressed, so are all of the FileMaker application menu items as well. Basically, the screen is black except for the layouts you create. This puts you, the developer, in complete control of the user interaction -- so much control that the user cannot even quit the application. The burden is now on the developer to script the entire solution. This type of solution architecture is perfect for registration kiosks, searchable information kiosks and the like. The Developer Edition comes with an example of a kiosk mode solution and covers in good detail all of the design considerations when developing a kiosk mode solution.
Most intriguing in my opinion is the ability to permanently remove access to Define Fields, Define Relationships, ScriptMaker, and Access Privileges. This capability was disturbing to developers because it provided a way for others to access and change their work. With the ability to permanently remove access to these areas, it is, for the most part, like distributing compiled code that cannot be deconstructed, protecting the intellectual property of the designer.
Another new feature is the ability to suppress the "Made with FileMaker Pro" splash screen that previously appeared whenever you closed a runtime solution. This was a highly requested feature by developers and is a welcomed enhancement. To take this one step further, you may want to create a closing script that swings by a layout for a few seconds and display your business and logo.
The Custom About and Custom Help script features allows you to navigate your users to your own about and help information through the standard operating system menu items. For example, if the user selected Help from the menu, you could have it trigger a script that takes them to a layout containing your own help information which pertains to your solution. The Custom About script would take you to a layout containing your company and possibly contact information.
The last new binding option offers the ability to rename the Script menu, another highly requested feature of developers. This feature simply adds further customization of your solutions running under the runtime engine. Imagine that your reporting database lists all of the possible reports under a menu named "Reports." Pretty elegant.
The Extension Convention
The three-character extension convention is similar to the Windows platform. What it does is associate the solution files to the runtime application. It is important to choose a unique extension so that another application on the hard disk doesn't attempt to open the solution. On the Mac OS platform, the three-character extension becomes that creator code for the solution files. The Windows platform will know to open the solution files with the runtime engine they were bound to.
Where It All Goes
The last panel requests the folder location where the runtime engine and copies of the solution files will be created. The important word here is copied. In the past, the original files were bound to the runtime engine and if you would have been able to choose to permanently remove access to define fields, relationships etc., you would permanently change your source files. Now, the Binder is risk free. All you need to do is click on the Select button and navigate to the desired destination and you're done.
What Has Changed
The earlier version of the Binder really consisted of one dialog where you filled in the primary file name, specified auxiliary files, selected from a much more limited list of binding options and assigned the key and extension. The only glaring omission from the earlier version is the issue of networking -- there isn't any. That's right, no networking capability in this latest offrering. No Hostng. No Guesting. No Networking. For this reason alone, I'll keep the old SDK around.
## END ##