Technique: Start It Up

FileMaker FUNdamentals: Start It Up -
Time Bombs, Keys and Layout Sizes
by Geoff Wells <>

RATING: Intermediate
PLATFORM: Macintosh & Windows
VERSION: FileMaker 4/5

I'm going to cover three apparently unrelated topics this month, but, as you will see, they all come together in the "Startup" script.

Time Bombs

It is an unfortunate fact of life that clients do not always pay their bills. As a developer you need a way to ensure that you are compensated for your hard work.

It's also true that clients will fail to delete an old build when you send them a new one. You don't want a client to use an out of date build but you do want to preserve a client's data even when your invoice is way overdue. The best solution is a time bomb that simply closes the file when a preset period of time has elapsed. A couple of flags and a script that runs at startup are all that you need.

We'll start by creating a MENU.FP5 file and adding some of the fields and scripts that you would normally need in your menu template. If you recall from last issue's article "Electronic Breadcrumbs" on how to create a [Back] button, I like to start each project with a template that contains my library routines.

Open Define Fields and add two global fields. A date global called Expire{Date} and a number global called Expire{Flag}. You will also need a calculation = 1 called Constant and a global number called Flag{UnLock}.

Next we add two scripts, "Time Bomb" and "Close". We add "Close" first because it is called by "Time Bomb".

Script: Close

Close[ ]

We'll modify this a bit later but it will do for now.

Script: Time Bomb

# "Is this a finished and paid for database where the Expire{Flag} is set to -1?" If [ Expire{Flag} <> -1 ]
# "Access sets "Expire Flag" to zero each time the database is opened, which adds 30 days to the time bomb."
If [ Expire{Flag} = 0 ]
Set Field [ Expire{Date}, Status(CurrentDate) + 30 ]
Set Field [ Expire{Flag}, 2 ]
End If
# "Prevent someone resetting clock to defeat time bomb."
If [ Expire{Date} <= Status(CurrentDate) or Expire{Flag} = 1 ]
Set Field [ Expire{Flag}, 1 ]
Perform Script [ "Close" ]
[ Sub-scripts ]
End If
End If

If you have no further need for the time bomb you can either delete the script or change the Expire{Flag} global to a calculation equal to minus one.

If the Expire{Flag} is anything other than minus one we next check to see if it is equal to zero. Later on we will see how the KEY.FP5 file is used to set the Expire{Flag} to zero each time it is opened. Each time you use the key to open the file the Expire{Date} is set to 30 days from today. The Expire{Flag} is then set to two because we do not use two as a flag for anything.

The previous test will only succeed if the key has been used to open the file. Next we check the Expire{Date} to see if the user has exceeded their time. If so we set the Expire{Flag} to one and close the file. If the user tries to set the system clock back the check will still succeed because the Expire{Flag} is now set to one.

Key File

The key file is used only during development and must not be referenced in anyway by the solution files.

If your solution is password protected, each file will have a minimum of two passwords. Your master password and a user password that can be set as the default in the document preferences. A key file can automatically enter your master password, set the time bomb and put the solution into development mode.

It's a very simple file with just one field, one relationship and one script. The field is the Constant =1 calculation, the relationship is ConstantMenu between the Constant in each file and the script is "Start Up" which is set to run each time the file opens.

Script:Start Up

Set Field [ ConstantMenu::Flag{UnLock}, 1 ]
Set Field [ ConstantMenu::Expire{Flag}, 0 ]
Perform Script [ Filename: "MENU.FP5", "Startup" ]
[ Sub-scripts ]

The script is used to set some flags in the MENU file then run the regular "Startup" script in MENU.FP5. Flag{UnLock} sets development mode and Expire{Flag} we covered in the Time Bomb section.


To make this work the KEY.FP5 file must have the same master password as the MENU.FP5 file. In our demo file this password is set as "ISOmagazine". Use the document preferences of the KEY.FP5 file to enter this as the default password and to run the "Start Up" script when the file is opened.

FileMaker will then open the MENU.FP5 file using this master password and you will have full access.

I normally add a "Close" script step to the key file "Start Up" script because once the menu file is open you don't need the key anymore. The only problem is the key is then set to open and close and you can't edit it. You can get around this by starting to define a relationship from any file in your solution to the key file. This will open the file without triggering the script and since your solution files have the same master password you will have access to the key. Be careful that you do not actually define any relationship because once you send the solution to your client the primary file will be looking for the key file which will be missing.

Development Mode

Writing custom or shrink-wrap solutions often require that your files are password protected. If you use scripted navigation or control access to records, it's important to close and lock the status area. This is fine when a solution is complete but it can get in the way during development.

While designing a solution you need full access to all of FileMaker's features. The finished solution will most likely have many of those features turned off. A flag that is set by your key file can control access to these features.

Script: Lock&Unlock

# "Unlock screen if running in development mode. - Key.FP5 sets to 1 (true)"
If [ Flag{UnLock} ]
Toggle Status Area
[ Hide ]
Set Zoom Level
[ 100% ]
Toggle Status Area
[ Hide, Lock ]
Set Zoom Level
[ 100%, Lock ]
End If

The above script is called as part of the start up routine. If the file is opened in the normal way the status area and the zoom level are locked. If the file is opened by the key file the Flag{Unlock} field would have been set to true (1) and the file will be unlocked.

The Size Layout

Decide on a standard window size for each layout in your solution. If you are writing for both Mac and Windows you should be aware of the different requirements of each platform. Monitors are getting bigger and screen resolutions are getting higher. 640 x 480 used to be the standard but on today's systems a layout designed for these dimensions will most likely end up as a tiny picture in the corner of the screen.

If you know the size of the screen used by your client then by all means design to that. You could use a multiple layout approach where you check for platform and resolution before you display each layout and go to a screen specifically designed for those parameters. This is possible in small systems but will quickly become a maintenance nightmare for more than a couple of layouts.

The important thing to remember is that the layouts should be consistently sized and neither the horizontal nor vertical elevator bars should appear. You may think all this concern over the size of the layout is being too anal, but the appearance of elevator bars is one of the first things a developer will look for when evaluating the work of a potential employee.

For our demo file we will take a middle of the road approach and design layouts for Mac and Windows that fill the screen at a resolution of 800 x 600. Use the Macintosh/Windows button on the menu layout to toggle between the two layouts and see the difference in sizes. Notice that the new Aqua interface for Mac OSX has different requirements than OS9.

Create two blank layouts in MENU.FP5 called Macsize and Winsize. Delete the header and footer parts and on the Macsize layout use the rectangle tool to draw a rectangle 770 x 535. On the Winsize layout make the rectangle 780 x 524. To be sure you have the exact size enter layout mode and select View>Object Size. Click the units indicator until you see "px". When an object is selected the overall dimensions are shown in the boxes marked with the double headed arrows.

Make sure both rectangles are pushed into the top left-hand corner of the screen and move the body part up to touch the bottom of the rectangle. Set the fill and line to null. Select the body part tab and fill with the 3rd gray from the bottom of the first color swatch column. The size layouts are used to provide a known standard that your solution can call anytime to set the dimensions of your GUI window. They are also useful in a multi-file solution as a neutral layout for a file not currently in use. Before moving to another file in your solution call the ScreenSize script to select the blank layout. If a user inadvertently chooses the window they will not be confused with irrelevant data. You might want to place a single [Menu] button on the layout so the user can navigate to a known location.

Script: ScreenSize

# "Macintosh"
If [ Abs(Status(CurrentPlatform)) = 1 ]
Go to Layout [ MacSize ]
End If
# "Windows"
If [ Abs(Status(CurrentPlatform)) = 2 ]
Go to Layout [ WinSize ]
Toggle Window
[ Maximize ]
End If
Toggle Window
[ Zoom ]

Startup Script

All the above scripts are brought together by the MENU.FP5 Startup script.

Script: Startup

Allow User Abort [ Off ]
Perform Script [ "Initialize Globals" ]
[ Sub-scripts ]
Perform Script [ "TimeBomb" ]
[ Sub-scripts ]
# "Time bomb not in effect so open balance of solution files."
# "If plugins are required Perform Script [Sub-scripts, "PluginCheck"] here"
# "•••••••••••••••••••••••••••••••••••••••"
# "Place plugin check scripts here"
# "Use a script for each plugin you require"
# "•••••••••••••••••••••••••••••••••••••••"
Perform Script [ "ScreenSize" ]
[ Sub-scripts ]
Perform Script [ "Lock&Unlock" ]
[ Sub-scripts ]
Set Field [ Back{History}, "" ]
Show All Records
# "Is the program running under Windows?"
If [ Abs(Status(CurrentPlatform)) = 2 ]
Toggle Window
[ Maximize ]
End If
Perform Script [ "GoToMy{Menu}" ]
[ Sub-scripts ]

Another "Standard" script is "Initialize Globals", used to make sure any values your solution needs will be available even if the file is cloned, (which will clear any globals).

If you are using a [Back] routine the Startup script is a good place to clear the Back{History} field.

Finally, but very important, each time the file is closed you must set the flag field Flag{UnLock} to false so that if the file is opened without the key file it will open with the status area locked.

Script: Close

# "Unlock flag is set to 1 (true) by Key.FP5 and is read by the Lock&Unlock script"
Set Field [ Flag{UnLock}, 0 ]
Close []

If you have any ideas for topics you would like me to cover in future articles; I would love to hear from you.

Happy FileMaking!

Geoff Wells is the author of the shareware program MIXOLOGY available from <>. Search the database of close to 1500 drink recipes by name, liquor or mix. Geoff is a Senior Editor at ISO FileMaker Magazine. Email him at