¶ Low Impact Startup
Originally proposed and submitted by Perren Smith.
As a best practice, for the sake of both network efficiency and enhanced security, it is suggested you create one (1) empty or single record table with a limited number of fields and one (1) dedicated layout and name them such that it identifies the table and layout as the file's startup elements. Naming the Table, Table Occurrence and Layout name "Startup" is highly suggested.
¶ Implementation
A startup table intended to have either zero or one record is added to the file. The reason for a single record is for when a startup-based user validation scheme is implemented (see Extended features below).
The startup layout should be associated to a table occurrence tied to the empty table (or single record), and should be the selected layout for the Switch to layout: check box within the File > File Options... settings.
Using the OnFirstWindowOpen: option within the Script Triggers area of the File Options dialog is the preferred method for arriving at any default target layout for solution startup. This script can evaluate account name, privilege set or any other variety of settings to determine which layout a user should end up on. (e.g. a Mobile vs. Desktop layout)
It is suggested that the Startup Layout be the topmost listed item in Manage > Layouts.
¶ Reasoning & benefits
Reduced startup overhead is realized based on the following benefits.
- Startup layout is ensured to be local to the file (meaning it is not accidentally or intentionally associated to any external files). The Startup table occurrence should not be connected to any external files!
- Startup layout is not connected to context based solution data. No data to load, nothing to evaluate - very fast. There are a few exceptions/benefits as documented below.
- Faster PSOS (Perform Script On Server) performance.
- Provides supplemental security to the file, in that the startup layout and table contain no fields, connections or elements which are immediately accessible.
- Script based branching provides total control of where to take the user.
This method of startup ensures the file is opened to a known location with a low load impact, because graphics (other than a potential splash screen) and other elements are not loaded until navigation takes the user to the target layout.
It also prevents the accidental last layout issue because FileMaker remembers the last viewed layout when the file was closed as a locally opened file. This means the file, when opened over the network, without the Switch to layout setting set, would default to the last viewed layout.
¶ Extended features
The Low Impact Startup comes with many additional features. These are just a few.
- The Startup layout can also serve as the Splash screen to your solution. By simply using a Pause/Resume Script step within your Startup script for a few seconds you can present a pretty picture.
- User validation and settings can be easily added. By simply adding a single unstored calculated field of
Get ( AccountName )and one record to the startup table, a one-to-one relationship to a Users table allows for both validation and the ability to load user specific settings. Note: Security must be set within the privilege set such that any given authenticated account can only see its respective record within the Users table. - Optional layout-based variable initialization. Because the layout is always targeted on startup, an evaluated text block can be used to create variables. Variable creation, of course, can also be done via script steps in the Startup script. This method simply allows for single-location easy editing when more familiar with text editor based coding vs. Claris/FileMaker's multiple script steps.
