FileMaker Templates

General

I put this on my website a long time ago, maybe around 1996, as an HTML page. This is it moved to my blog.

Introduction

Development and maintenance of complex FileMaker solutions is far easier when you have built your solutions from templates. Because:

  • You’ll be able to throw together solutions in a quarter of the time it normally takes to do a version 1.
  • You’ll know it is robust because the template is tried and tested.
  • You’ll be able to look at each solution and know that it obeys certain set principles, which saves time when fixing problems or adding new functionality.
  • You’ll be able to create a User Manual and Developer Documentation in a fraction of the time because most of that text is the same for all the solutions you create.
  • You’ll be able to store details such as Company Name and Address in a System Constants file and use them all over the system. Just change these System Constants when you sell the system to someone else.

You can download my own templates here (the high-level password is colonelklink):

These templates are arranged in 3 folders:

  • Basic Templates – Regular.FP3 for a regular form view file, Lines.FP3 for hidden files such as Invoice Lines, and others.
  • Functional Templates – a Contacts tracking system, an Invoicing System
  • Other Templates – including a mail-merging system.

These templates represent a considerable head start when developing FileMaker systems. You are welcome to use them but naturally I accept no liabilities and offer no guarantees. If you use them it would be nice to receive a comment.

The following is both a description of these templates and general advice about FileMaker templates. Be sure to read Murray’s FileMaker Advice to learn about basic techniques which should be used in all FileMaker development.

Layouts

  • Menu
  • Edit Details
  • View Details
  • Find
  • List
  • All Fields

Menu

Each file should have its own menu with buttons for Details, New, Find, List.

Edit Details

The buttons at the side include the standard group (Menu, Details, New, Find, List) and the navigation box with CD-type controls and record numbers etc. Specific buttons for reports etc should be place in the second group. When changed, this set of buttons should be grouped with the Navigation Box (see below) and copy-pasted into all other details screens using the Size window to ensure exact positioning.

Having the buttons on the left allows room in the main part for 2 columns of fields. The standard screen is not wide enough for three columns at a readable point size and spreading 2 columns over the whole width wastes space.

There may be several details screens to show various groups of data. All details screens should have the same bar at the top, showing the record number and one or two other particularly important fields. This helps prevent the user from losing track of what record they are looking at, and emphasises that they are looking at different fields within the same record.

View Details

The View Details layout is created by copying and pasting the form section of the Edit Details layout into the View Details layout. Use the Size window to place it in exactly the same position. This should then be sent to the back of the layout, behind the large rectangle which is defined as a button to prevent access. Create a New Tab Order with no tabs to prevent users from tabbing behind the rectangle.

Find

The Find screen is mostly a duplication of the Details screen with some differences.

The Find layout is created by copying and pasting the form section of the Edit Details layout into the View Details layout. Use the Size window to place it in exactly the same position. Remove buttons, such as the circle button in portals, which do not belong on a find screen.

  • The New button creates a new Find request instead of a new record.
  • The navigation buttons do not perform any processing. (see below).When changes are made to the details layout, the fields should be re-copied to the Find layout. The Find button uses a trapped find script which does not allow the user to ever be left on the Find layout in Browse mode. The Find layout may be in a different colour to emphasise that the user is in Find mode.

 

Once the find is performed the script will go to the Details or List layouts depending on whether more than 1 record was found.

List

All files should have a list layout. Clicking on the button on the left takes the user to the Details for that record.

The [Sort] button allows users to sort by any order. The Column headings could also be defined as Sort buttons but this is difficult to maintain.

All Fields

This layout is for general system maintenance and should be used by scripts whenever it is absolutely necessary to use cut/paste instead of set field().

This layout can be updated by creating a new layout, Copying all fields, deleting the layout, going to All Fields, Deleting All Items, and Pasting the new fields.

The Navigation Box

This set of fields and buttons allows the user to move through the records without having to open the status panel. When in browse mode, the buttons also ensure that the SUB.Process script is called on each record. The panel also includes a [Del] button.

Scripting

SUB.Process

It is sometimes necessary to ensure that data is validated or updated using scripts whenever it is changed. Ensuring that all buttons call this empty script allows the developer to insert such processing in future without having to modify all the button scripts. Therefore, all new Button scripts should be created by duplicating an existing Button script.

N.B. This method will allow the developer to create indexed versions of un-indexable fields for fast finds and extra relationships.

Scripts Menu

The scripts menu should be used as a menu to move between areas in the entire system. This also discourages use of the Window menu.

Special Fields

Sys.Found, Sys.Records

Used by the Navigation Box.

Sys.Creation Date, Sys.Creation Time, Sys Modification Date, etc

Additional Information to help the developer maintain database. Remember, these fields are usually not auto-entered in imported records.

G.Help.Code, G.Help.Applescript

Can be used for context-sensitive help. Specific Help buttons set a Help Code in G.Help.Code and a SUB script then displays the relevant text from the ‘System Help’ file. Because the FileMaker message box is of limited size, the G.Help.Applescript field can be used to generate an Applescript dialog box. The field already contains the necessary Applescript but needs to be altered to refer to your help file via a relationship.

Sys.StatusCurrentError

Used by scripts to trap errors. See the ‘BUTTON.Find’ script for example.

Sys.File Name

see ‘Global Fields’ below.

LINK

This calculation field is always 1. It can be used by a relationship to get at values in the System Constants file.

Global Fields

‘Sys.File Name’ is used on layout headings and in the label for the Primary Key. It should be entered as a singular rather than plural. The ‘s’ has been added to the layout where necessary. Calculated plural and singular fields would not show up in Find mode. Because this field is wiped when a clone is saved, the script ‘SUB.Set Sys.File Name’ is called from the Open Script. This resets the filename if it is empty. Therefore a new filename should be entered in All Fields and in this script.

Global Fields must not be used for button names because these fields will be wiped when a clone of the file is saved.

Portals

The file contains an example of a portal. This same arrangement should be used for all Portals. The portal has a circle button at the left which takes the user to the details for that item. If the portal is being used to add lines then the portal should have a Del button at the right.