Creating and managing layouts is one of the most important tasks required of a FileMaker developer. It's also one of the most intuitive. There are, nonetheless, numerous subtle facts and details that you need to know. We encourage you to have a test file open as you go through the following sections so that you can try things firsthand.
Creating a New Layout
Every time you create a new table in a file, FileMaker automatically creates a new layout for you as well, based on the new table. The layout is given the same name as your table, and all the fields you defined at the time of table creation are placed on the layout for you. Figure 4.1 shows an example of what this default layout looks like.
Figure 4.1. The default layout created when you add a new table to a file.
You can create new layouts anytime you want while in Layout mode simply by choosing Layouts, New Layout/Report, or by pressing (N) [Ctrl+N]. You are then taken to a setup wizard that can help you configure a layout according to one of a handful of types of common layout designs. Figure 4.2 shows the first screen of the Layout Wizard, on which you specify a name for the layout and choose a layout type. You also specify a layout's context here; that topic is covered in the next section.
Figure 4.2. This is the first screen of the wizard for creating new layouts.
You can create the following six types of layouts:
We do not discuss all the screens of the New Layout/Report Assistant here; they're quite intuitive, even for new developers. Besides, if you are new to FileMaker, nothing beats spending an hour just playing around with the assistant to see firsthand what the various configuration options do for you. You won't cause harm to any existing layouts by doing so, nor can you hurt the database even if you mess up the creation of a new layout.
After a layout has been created, it can be completely modified and turned into whatever you need it to be. Much of the remainder of this chapter is devoted to the tools at your disposal to do just that.
No tool is available for importing layouts from one file to another. If you ever need to do this, the best method is to set up a new, blank layout with layout parts sized the same as the source layout. Then, copy all the objects from the source file and paste them into the new file. Fields, buttons, and portals need to be respecified to point to their correct referents, but at least all your formatting will be retained.
Within a file, you can duplicate layouts by choosing Layouts, Duplicate Layout. Often, this is a preferred method for creating new layouts, even if they end up looking significantly different from the original. Part sizes, graphic elements, and formatting options are all retained, so modifying as necessary with these as a starting point is usually much faster than creating new layouts from scratch.
Create a template layout for yourself that has examples of all the necessary bits and pieces specified (portals, fields, field labels), along with color squares and grid lines. Then you can simply duplicate your template when you need to create a new layout, and you'll be well on your way to a finished product.
Every layout is linked to a table occurrence from the Relationships Graph. Many layouts can be linked to a particular table occurrence, but each layout must be tied to one, and only one, table occurrence.
For more information on table occurrences, see "Adding a Table Occurrence to the Relationships Graph," p. 187.
The reason layouts need to be associated with table occurrences is that in a multitable file, FileMaker needs some way of knowing which records to display in a given layout. In the old days when FileMaker allowed only one table per file, it was always clear that layouts in file X should display records from table X. Now, layouts in file X can be configured to display records from table A, B, or C. The context of a layout is determined by the table occurrence to which it is tied. Context, in turn, determines the table from which the layout will show records, and also establishes the reference point for other types of operations, such as displaying data from related tables, or evaluating calculations that reference related tables.
The concept of layouts being tied to table occurrences can be a bit confusing. See "Determining Which Records Will Be Displayed on a Layout" in the "Troubleshooting" section at the end of this chapter.
You might wonder why layouts need to be associated with table occurrences and not source tables themselves. If you were concerned only with displaying records from the source table, you wouldn't need to worry about table occurrences. But layouts also need to be able to contain records from related tables (that is, portals), and relationships are built between table occurrences, not between source tables. Having a layout linked to a table occurrence makes it unambiguous what context should be used to access related records.
Consider it in terms of perspective. To view any data within your solution, your user needs a starting point, or perspective, and an end point. For example, you might be looking from Company Detail through a portal to Employees related to that company record. The associated table occurrence tied to a given layout serves as a user's starting point, and any related data will be viewed from that table occurrence's perspective on the Relationships Graph.
If you're unfamiliar with relational data modeling or how to display related data in FileMaker, we recommend that you see Chapter 5, "Relational Database Design," p. 129, and Chapter 6, "Working with Multiple Tables," p. 157.
When you define a new layout, the very first prompt of the New Layout/Report Assistant lets you specify where to show records from. The options in the pick list are all the table occurrences from the current file's Relationships Graph.
If you do have multiple occurrences of any of your source tables, the selection of a particular occurrence in no way affects your ability to see or edit field data in the source table itself. That is, if you don't intend to put any related fields on the layout, it's likely to be inconsequential which occurrence of that source table you select. Do realize, however, that context for scripts is determined by the currently active layout, so some scripts might behave differently if one or another occurrence is used.
The implications of context for scripting are discussed elsewhere; see "Script Context and Internal Navigation," p. 260.
The Layout Setup dialog, accessed under the Layouts menu, allows you to edit many of the fundamental characteristics of a layout, such as the name of the layout, its context, and how it can be viewed (see Figure 4.3).
Figure 4.3. The Layout Setup dialog is where you go to change things such as the name of a layout and its context.
You have a great deal of flexibility in how you name layouts. Layout names do not need to be unique and can be up to 100 characters long. They can include numbers, symbols, spaces, and pretty much anything else you want to use.
Although flexibility is a good thing, we suggest that you follow a few guidelines:
The single-hyphen naming trick works in other areas of FileMaker as well, such as within value lists and as a script name.
Every layout you develop can potentially be viewed in three ways: as a form, as a list, or as a table. A user with access to standard menu commands can use the View menu in Browse mode to switch between them. When you navigate to a layout, you will see it in whatever state it was last saved in, so bear in mind that switching from layout to layout may change the view setting as well.
The differences between the three view types are quite straightforward:
Figure 4.4. You can alter the look and functionality of the table view by using the Table View Properties dialog.
Using the Views tab of the Layout Setup dialog, you can disable user access to certain view types. Although usually not necessary, this can be a good precaution to take to keep adventurous users on the right track. Accessing an inappropriate view type is likely not going to cause much harm, but it certainly can confuse users.
When printing labels and certain types of reports, you might want to present your data in multiple columns. You can specify the number of columns to display on the Printing tab of the Layout Setup dialog; this is shown in Figure 4.5.
Figure 4.5. You can customize the print settings for a particular layout on the Printing tab of the Layout Setup dialog.
In Layout mode, dashed vertical lines represent the boundaries between columns. Columns other than the first are grayed out; the idea is that you need to place any objects you want displayed in the first column, and these objects are replicated to the other columns as necessary. Figure 4.6 shows an example of a three-column layout used to display a phone directory. Notice that the header and footer part are not divided into columns. This means that if you want headers to appear above the second and third columns, you need to add those explicitly, as we've done in Figure 4.6.
Figure 4.6. This example shows how a layout for a three-column phone directory might appear in Layout mode.
It's not possible to have columns of differing widths; every column is the same width as the first one. You can manually adjust the column width by clicking on the dashed divider between the first and second columns and dragging left or right as appropriate.
Subsummary parts and leading and trailing grand summaries can be used on multicolumn layouts, but they behave slightly differently depending on whether you've chosen to display data Across First or Down First. If you chose Down First, any summary parts are also columnar. On the other hand, if the data is displayed Across First, summary parts span the full width of the layout, just as the header and footer parts do.
Subsummary parts are covered in depth in "Working with Parts," p. 103.
The effects of a multicolumn layout can be viewed only in Preview mode. In Browse mode, a user sees only a single column of data.
Hiding and Reordering Layouts
In Browse mode, layouts can be designated to be either accessible or inaccessible via the layout pull-down menu in the Status Area. If a layout is accessible, users can see it and navigate to it at will (assuming that the Status Area is visible and/or accessible). If the layout is inaccessible, users can navigate to it only by running a script that takes them there. (In Layout mode, all layouts are accessible.)
Typically, layouts are set to be inaccessible when you need to prevent users from manually navigating to a layout. For instance, you might have report layouts or find screens that require certain preparation before they become useful. There may be unanticipated and/or undesired results if a user is able to bypass the scripts you've created and navigate directly to a layout.
The option to have a layout be accessible or not is on the first screen of the New Layout/Report Assistant; it can also be set through the Layout Setup dialog. The Set Layout Order dialog, shown in Figure 4.7, also has a check box on each line that can be toggled to change a layout from visible to hidden and vice versa. Using this method is the quickest way to hide (or show) a number of layouts at once.
Figure 4.7. Use the Set Layout Order dialog to set the accessibility and order of layouts.
The Set Layout Order dialog, as you might guess from its name, also enables you to change the order in which layouts appear in the layout pop-up list. You can use the double-arrowed selection tool to move a layout up or down in the order. You can accomplish the same thing by selecting a line and pressing () [Ctrl] and the up or down arrow.
In FileMaker 6 and earlier versions, you were required to be the host of a file to access the Set Layout Order dialog. It can now be managed even as a client of FileMaker Server.
Restricting Access to Layouts
Using the methods discussed in the preceding section to hide layouts is a good way of keeping users from going places they shouldn't, but it's not adequate security if you truly need to restrict access to layouts. Moreover, making layouts inaccessible affects all users; you can't set up rules determining which layouts are accessible for which users.
Added protection for layouts can be achieved by restricting access via security privilege sets. A privilege set can be defined to provide All No Access, All View Only, or All Modifiable control over all layouts at once; alternatively, you can specify custom layout privileges for each individual layout, as shown in Figure 4.8. You can protect editing of the layouts themselves, as well as the data displayed on them. Any user who has no access to a layout doesn't see that the layout exists, even in Layout mode.
Figure 4.8. Custom layout privileges enable you to restrict certain users from modifying or viewing certain layouts.
For more information about setting up privilege sets, see "Working with Privilege Sets," p. 334.
If you want to prevent certain users from creating new layouts, leave the Allow Creation of New Layouts option at the top of the Custom Layout Privileges dialog unchecked. Additionally, you can set default privileges that users will have for new layouts by editing the options for the [Any New Layout] line.
Note that the preceding security settings allow developers to give users the ability to edit some layouts and not others, and also to create their own layouts (or not). It is possible in FileMaker to establish "junior developer users" who can exercise a degree of freedom within certain areas of a given system without jeopardizing critical or more complex areas.
Working with Parts
Part I: Getting Started with FileMaker 8
Using FileMaker Pro
Defining and Working with Fields
Working with Layouts
Part II: Developing Solutions with FileMaker
Relational Database Design
Working with Multiple Tables
Working with Relationships
Getting Started with Calculations
Getting Started with Scripting
Getting Started with Reporting
Part III: Developer Techniques
Developing for Multiuser Deployment
Advanced Interface Techniques
Advanced Calculation Techniques
Advanced Scripting Techniques
Advanced Portal Techniques
Debugging and Troubleshooting
Converting Systems from Previous Versions of FileMaker Pro
Part IV: Data Integration and Publishing
Importing Data into FileMaker Pro
Exporting Data from FileMaker
Instant Web Publishing
FileMaker and Web Services
Custom Web Publishing
Part V: Deploying a FileMaker Solution
Deploying and Extending FileMaker
FileMaker Server and Server Advanced
Documenting Your FileMaker Solutions