1-more-thing

FileMaker 2023 20.2 – Layout Calculations – Video

Written by

Fabrice

in

, ,

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.

Comments

6 responses to “FileMaker 2023 20.2 – Layout Calculations – Video”

  1. Joseph Avatar
    Joseph

    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.

    Reply
    1. Fabrice Avatar
      Fabrice

      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)

      Reply
  2. Jerry Avatar
    Jerry

    I don’t get why this is better than a one button button-bar.

    Reply
    1. Fabrice Avatar
      Fabrice

      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

      Reply
    2. Fabrice Avatar
      Fabrice

      Another advantage is the fact that text objects slide/resize. Very handy for print layouts, especially in list view.

      Reply
  3. Steve Avatar
    Steve

    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.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts