QUE CORPORATION - Using Filemaker pro X

Showing/Hiding Contextual Layout Elements

In addition to presenting various windows for your users, there are times as a developer that you'll want to control whether or not users have access to specific functions on a current layout. A simple example might be a Delete button: Not everyone who uses your database should be given delete privileges. If you have placed a button on your layouts for deleting records, you'll need to either trap for an un-authorized attempt to use it (and likely present a graceful , "you're not permitted to do that" message with FileMaker's security settings), or craft separate layouts that offer both the "full" and "limited" functionalities you need.

Creating a new layout for each case in which you want to hide or display specific layout objects is obviously a technique you'll want to use sparingly. Any change made on one of these duplicated layouts requires that you change all versions. This quickly can become a maintenance nightmare. Conversely, there are many useful applications of being able to conditionally display information and functions. Imagine a social security field that appears only for members of your HR department. Another scenario might be a tab in your user interface that only administrators can see or click. A third possibility could include Submit and Cancel buttons appearing on screen only after someone has modified available fields. You certainly won't want to have to create separate layouts for each of these cases. Pragmatism will be at odds with UI design.

To get layout objects to appear and disappear based on some programmatic condition, use portals. In addition to displaying data fields, portals can contain layout objects in FileMaker Pro. When one or more records are related to the table occurrence associated with your current layout, their rows appear in a portal, along with any buttons or other layout objects you've placed there. When there is no valid related data, neither the data itself nor layout objects appear. If a user were to click in that area of the screen, nothing would happen.

A simple example is shown in Figure 13.11.

NOTE

Although the portal displayed here has a border for clarity, in your finished solution you'd likely want to make it invisible by applying no border.

You can implement this sort of functionality in your database solutions in a variety of ways. The simplest approach is to create an "on/off" resource table (simply a table you'll use as a developer to store internal logic) with one record. When necessary, simply relate to it by populating a global in your main user interface table with perhaps a constant that matches the same in the resource table. Place whatever layout objects you need in its single portal row. Because you won't be drawing from any data in the resource table, you need only as many records as you expect to display in your "contextual" portal rows.

Another approach gives you more flexibility: Add button labels and script parameters to your resource table. To control which button appears in your portal, change the resource match key. If you use script parameters pulled from the related row, you need not bother changing the script attached to your button. Simply use an If/Else switch script to point your buttons to the appropriate scripts. If you need to add more contextual functions to your database, simply create a new resource record.

These techniques are driven by a resource key in your current table (and table occurrence as dictated by your current layout). By using a multi-key, you can offer multiple, contextual buttons when appropriate (see Figure 13.12).

To explore managing multi-key match fields, see "Multi-keys and Multi-row Selections," p. 460 .

Another dimension for these techniques is working horizontally. By specifying the starting row for a portal, you can have multiple buttons appear side by side. This would work well for the resource file example (see Figure 13.13).

Another application of this technique can be even more specific to your database. Consider cases where often you don't have the screen real estate to display multiple portal rows, and would like users to have a stronger visual cue than just a darkened scroll bar for additional associated child records.

Instead of pointing to a resource database, these techniques can also be applied to actual data tables. Imagine a series of tabs appearing in cases where you, say, have more than one mailing address for a contact (see Figure 13.14). Another example might be where you want to have available multiple pieces of account information for a customer.

The various applications for this technique are wide ranging . We encourage you to use it once or twice so you're familiar with its implementation. After you've got it comfortably added to your toolbox, your creativity will kick in and you'll spot cases where you can use it to great effect.