Layout Calculations in FileMaker 20.3

Update 12 Dec 2023: this article has been updated as per my exchanges with Fabrice Nordmann in the comments section below. Thank you Fabrice for the reality check.

This is a follow up to last month’s article, Layout Calculations in FileMaker 20.2, and will assume the reader is familiar with that material. Today we will be taking a look at some changes to Layout Calculation behavior in the newly-released FileMaker 20.3.

#1. Calculation Result Type Can Now Be Specified

We can now specify the result type for a layout calculation…

…whereas in FM 20.2, the result type could only be text.

Initially I was under the impression that this would yield benefits when applying, for example, date specific formatting options, but as Fabrice points out, the formatting behavior is identical regardless of what you do with the result type.

For example, in layout mode, we can use the text tool to begin generating a block of text…

…and then choose Insert > Layout Calculation, enter this syntax and, if we choose, specify Date as the result type.

After clicking OK, here’s what we see in layout mode.

Note: the %D indicates a date result… other codes are %T for text, %N for number, %I for time and %M for timestamp. (When the result is text, the %T is optional.)

Next, let’s apply some fancy date formatting like so…

…and now we can view the results of our handiwork in browse mode.

But it turns out that the layout calc result type has no bearing on this, and we will see the same output if we go with the default result type of Text.

#2. Local Field Names Do Not Need To Be Fully Qualified

Field names from local tables no longer need to be fully qualified (i.e., preceded by “tableoccurrence::” ), and in 20.3 are inserted as field name only (i.e., without the leading “tableoccurrence::”) when you pick them from the field list in the Specify Calculation dialog.

BEFORE (FM 20.2)

NOW (FM 20.3)

However, bear in mind that while local field names in layout calculations no longer need to be fully qualified, they still can be, and in some cases should be fully qualified… for example, if you need your layout calculations to work in both FileMaker 20.2 and in 20.3.

Layout Mode

Browse Mode: FM 20.2

Browse Mode: FM 20.3

Another reason to use fully-qualified field names in your layout calculations is that they are more responsive during data entry.

Here I have updated all three fields but have not committed the record (as confirmed by the data viewer). The fully-qualified version of the layout calc updates on field exit…

…but the field-name-only version of the layout calc does not update even on record commit.

Getting the field-name-only version to update takes some sort of “refresh” action, such as switching out of and back into browse mode, changing records and then returning to the current record, refreshing the window, or, if you’ve assigned an object name, refreshing the object.

To be clear, this is only an issue if a) your layout calc references local fields, and b) you want to see changes made to local data reflected by the layout calculation in near real time.

Closing Thoughts

As is often the case with FileMaker there is more than one way to accomplish a task, and we get to decide what to include in a layout calc, and what to leave out.

For example, is it okay to embed all the logic inside the calc definition?

And the answer (as is often the case with FileMaker) is it depends. Yes we can do it, but custom formatting applied via the Inspector will be ignored.

But if we instead embed the layout calc within a larger block of text, e.g.,

…then custom formatting will be respected.

However, if we really want to do it all in a single layout calc, we can use a custom function such as Tim Mansour’s wonderful FormatTimestamp (https://www.briandunning.com/cf/629) to take care of the date formatting.

Dialog

Layout Mode

Browse Mode