Dynamic FileMaker UI Using Layout Calculations

Layout calculations in Claris FileMaker enable us to include dynamic elements in text objects. This is a deceptively powerful addition to FileMaker’s layout capabilities. We’ll describe how layout calculations work, and detail three interesting things about them.

How layout calculations work

Layout calculations are similar to FileMaker merge fields and merge variables in that they allow us to include dynamic elements in text objects. However, rather than limiting us to field, variable, or Get function values they give access to the whole FileMaker calculation engine, opening up more possibilities.

There are two ways to insert layout calculations: “freehand” or via the Insert menu.

Insert a layout calculation via the Insert menu

1. In layout mode go to the Insert menu and select Layout Calculation... or use the keyboard shortcut Command-Shift-C (Ctrl-Shift-C on Windows).
2. Define the calculation in the FileMaker calculation dialog.
3. Enter browse mode to see the result of the calculation on the layout.

Insert a layout calculation freehand

1. In layout mode using the text tool, create a new text object (or edit and existing one) and type <<ƒ:>>. Note: On macOS you can generate the ƒ character by holding option and pressing the f key.
2. Type any valid FileMaker calculation after the : character.
3. Enter browse mode to see the result of the calculation on the layout.

Editing layout calculations

• Layout calculations can be edited freehand by clicking into the text object and making adjustments.
• To show the calculation dialog for a layout calculation right-click an object containing a layout calculation and select Edit Layout Calculation... from the context menu.

Inserting multiple layout calculations in a single text object

As with merge fields/variables, multiple layout calculations can be included in a single text object. We will see why we might want to do this later in the post.

Three cool things about layout calculations

We will use the example of an art gallery sales database to tease out some cool features of layout calculations.

1. Layout calculations mean no more inappropriate button bars

A button walks into a bar and gets untitled.

When an artwork in our gallery database doesn’t have a title entered, we want to display “Untitled” on the layout rather than show nothing. We can achieve this with a simple If statement:

If ( IsEmpty ( Artwork::Title ); "Untitled"; Artwork::Title )

The button bar approach to displaying this calculation on the layout looks like this:

This displays the text with correct formatting but it has the following drawbacks:

• The button bar entry in the objects panel makes the purpose and meaning of the object unclear, as well as adding the visual noise of an unnecessarily nested element. It is not semantic (meaningful).
• The calculation definition is opaque and can only be accessed through the button bar setup dialog.
• We have had to create a duplicate of our H2 text style for our button bar so that it looks identical to the text object it replaces. If we change our H2 text style in the future, we will also have to remember to update the H2_ButtonBar style.

Let’s solve those problems by using a layout calculation. The layout calculation approach looks like this:

This displays the text with correct formatting and has none of the drawbacks of the button bar approach:

• The text object entry in the objects panel is simple and its meaning is clear. It is semantic.
• The calculation definition is clearly visible in the objects panel and the layout object itself.
• We are able to use the existing H2 text theme style.

2. Layout calculations offer flexible data formatting

Our gallery system has specific requirements for date and number formatting. In particular we want to display a description of the sale that formats the selling price including tax with currency formatting and the date as a “longhand” date with day name and month name. This is possible if we break our text object down into multiple layout calculations that return a number and a date respectively. Doing this allows us to leverage the features of the Data Formatting pane.

The cool thing is that the number formatting settings are applied to the layout calculation that returns a number and the date formatting settings are applied to the layout calculation that returns a date:

3. Layout calculation results can be referenced by other layout objects

The two reasons to reference layout calculations are to achieve advanced formatting and to improve performance.

Advanced layout calculation formatting

We have seen that the Data Formatting pane can be used to set formatting for multiple layout calculations with different data types in a single text object, but what if we want different formatting for two layout calculations that have the same data type? In this case we need to split our layout calculations into “source” and “presentation” layout calculations.

Our gallery has locations in US and UK, so it sometimes needs to display prices in both currencies. We can only define one data format for numbers, so our initial attempt to show the US price first followed by the UK price in parenthesis does not work:

To fix this, let’s define two source layout calculations, one for each price. We will position these off to the side of the layout, as they are not for presentation.

We need to name each of those objects so we can reference them in our presentation text objects. We namespace the objects with “Calc” for easy identification. The objects are named Calc_SellingPrice and Calc_SellingPriceGBP. We set the data formatting for each of these text objects to include the appropriate currency symbol, $ and £ respectively.

Now we can rewrite the layout calculation in our presentation text object to reference the source layout calculations. We do this using the GetLayoutObjectAttribute function:

This allows us to easily mix number formatting styles in a single presentation object:

Leveraging layout calculations to improve performance

Source layout calculations can also improve performance of layouts that rely on ad hoc calculations. Imagine if we wanted to display the top 5 states for sales along the top of our layout on our layout. We can get the source data for this using a SQL query:

ExecuteSQL (
  "SELECT
    StateSold
  FROM
    Artwork
  ORDER BY
    SUM ( SellingPrice ) DESC
  GROUP BY
    StateSold
  FETCH FIRST 5 ROWS ONLY";
  "";
  ""
)

Before layout calculations we would have to include the full query (or a variation of it) in each object where we wanted any of the top five selling states. This is a potential performance issue and it could become difficult to keep the queries in sync if their underlying definition changed over time.

With layout calculations we can define this calculation in a single source layout calculation, which can be accessed by as many presentation objects as required:

In the example below we see a scattered arrangement of 5 text objects each referencing the source layout calculation.

Source layout calculations: A schema for your dynamic layouts

Think of source layout calculations as a sort of “layout data schema” which can be leveraged by presentation text objects to achieve consistent, complex formatting and optimize performance of data-driven layout objects.

Cool thing (++) about layout calculations

Editor’s note: Alec promised he’d stop at only “three” cool things about layout calculations, but after writing the above, our FileMaker team came up with one more...

4. Layout calculations can be used a button labels

In this post we have focused on layout calculations in text objects, but they can also be used on labels for regular buttons using the freehand approach.

Here’s an example of button that adds 7 days to DateOnSale field while displaying the current date and the date if the button is pressed:

Demo file

Download the demo file to check out the above examples. FileMaker Pro v20.2+ is required.