Claris has just announced a new release of FileMaker, 20.2.
Among other new features and improvements, let’s take a closer look at layout calculations.
Video by Fabrice Nordmann
Updates:
I forgot to mention symbols in the video. Introduced very early (FileMaker Pro 2 or earlier), symbols like ## (page number), @@ (record number), “//” (current date)… were updated in FileMaker 15 (unsure). The notation {{RecordNumber}} allowed access to all Get function parameters. {{HostApplicationVersion}} for instance.
the new layout calculations being a subclass of the merge feature of text objects, it is possible to use them in labels of the old button/popover button objects. But there are important limitations to that, so you definitely won’t do it. These are:
the UI doesn’t allow access to the calculation dialog, so you have to type the formula precisely and without mistake
as opposed to simple text objects (new behaviour described in the video), buttons cannot be resized to a smaller size than their contents (in that case, the calculation formula), at least using the mouse (you can achieve this using the inspector)
New to FileMaker? Watch our Quick Start video and get started in 10 minutes.
Thanks for the recap of this feature. Layout Calculations will be a handy tool. As someone who started FileMaker dev around version 11, I appreciate the history and context you provided too.
Thank you.
I just realise that I forgot to mention the ‘symbols’, which had their own ‘syntax’ for long (hence the name), like @@ for Get ( RecordNumber ), ## for Get ( PageNumber )… and which were replace and extended to all Get functions with the following notation: {{RecordNumber}}… in version X (can’t remember)
In many ways 🙂
– Button bars are very “expensive” to load and to render.
– They are difficult to style in a way that is aligned with other text objects and fields (lots of useless attributes, states… for a simple text object)
– They prevent the implicit commit when you click on them, unless you turn them all into actual buttons that commit records (then you have all states to manage in terms of style)
– You can combine multiple merge data and formatting much more easily
On the other hand, text objects are resized when you double click them, which is, IMO, an undesirable behaviour. Button bar size is fixed
One issue with button bars is that you can’t rotate them. The layout calculations can rotate. I have had use cases where I have wanted to use two calculated button bars on the same layout, with perpendicular orientations. This wasn’t possible. And with layout calculations, it is possible.
Thanks for the recap of this feature. Layout Calculations will be a handy tool. As someone who started FileMaker dev around version 11, I appreciate the history and context you provided too.
Thank you.
I just realise that I forgot to mention the ‘symbols’, which had their own ‘syntax’ for long (hence the name), like @@ for Get ( RecordNumber ), ## for Get ( PageNumber )… and which were replace and extended to all Get functions with the following notation: {{RecordNumber}}… in version X (can’t remember)
I don’t get why this is better than a one button button-bar.
In many ways 🙂
– Button bars are very “expensive” to load and to render.
– They are difficult to style in a way that is aligned with other text objects and fields (lots of useless attributes, states… for a simple text object)
– They prevent the implicit commit when you click on them, unless you turn them all into actual buttons that commit records (then you have all states to manage in terms of style)
– You can combine multiple merge data and formatting much more easily
On the other hand, text objects are resized when you double click them, which is, IMO, an undesirable behaviour. Button bar size is fixed
Another advantage is the fact that text objects slide/resize. Very handy for print layouts, especially in list view.
One issue with button bars is that you can’t rotate them. The layout calculations can rotate. I have had use cases where I have wanted to use two calculated button bars on the same layout, with perpendicular orientations. This wasn’t possible. And with layout calculations, it is possible.