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 a layout calculation via the Insert menu
- In layout mode go to the Insert menu and select
Layout Calculation...or use the keyboard shortcut
- Define the calculation in the FileMaker calculation dialog.
- Enter browse mode to see the result of the calculation on the layout.
Insert a layout calculation freehand
- 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
optionand pressing the
- Type any valid FileMaker calculation after the
- 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 ( 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_SellingPriceGBP. We set the data formatting for each of these text objects to include the appropriate currency symbol,
Now we can rewrite the layout calculation in our presentation text object to reference the source layout calculations. We do this using the
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:
Download the demo file to check out the above examples. FileMaker Pro v20.2+ is required.