New Ultimate Display Power in FileMaker

Brought to you by www.filemakerm... - Here's a video about Layout Calculations and how they'll impact your future FileMaker development. Layout Calculations will revolutionize our use of Buttons and how we can display calculated values on screen.

[@stowlo]

A bit of my soul dies every time I load a button bar instead of a button for the calc. You have saved my soul lol!

[@MauiSolarPVPacificEnergy]

I have been waiting for this feature for 25 years. Thank you Claris and Matt for doing a deep dive.

[@tiller6750]

I can't wait to take this great new feature for a spin! Thanks for all that you do, Matt!

[@juniper_b0nsai245]

Thanks, Matt. The first I heard of this was in the patch notes - hoped you would put out a video going over it!

[@filemakermagazine]

There was very little mention of it for sure! Even the announcement you could find on the community site didn't say anything about it. community.claris.com/en/s/group/0F90H000000Xx78/claris-product-announcements

[@mk.h]

Below is what Claris (back then FileMaker inc) mentioned in the keynote a few years ago when we had our developer conference in Syd AUS. Each number represents the weight of object on the layout. Although it is a few years old but I imagine everything is still valid today. Note that there is no button bar so this is likely mentioned to us before version 14. - Overhead for various FileMaker Objects: - Line, 1 - Shape, 2 - Edit Field, 3 - Dropdown / Popup, 3 - Chart, 4 - Image, 4 - Text, 5 - Button, 7 - Web Viewer, 3+ cost of web page - Tab, 9 + layout object cost - Portal, 12 + layout object cost - Turning object in to button, +1 - List view >> form view - Object w/Data >> Objects without

[@filemakermagazine]

Thanks for the reply! You can actually discover some of this yourself if you modify the CSS using the last few functions I provide in the video. If you set all CSS borders to a solid 1 pt line and give them a different color you can see how many "wrappers" there are around enclosed objects. This is a fundamental of how HTML/CSS works and because FileMaker had adopted CSS it's an inherent part of what FileMaker has to process in order to translate and render to screen. Hence the reduction, as a button bar has many more wrappers than a text object.

[@ulfen69]

At 15:00 into the video you are trying merge variable in the button setup. Does it work on FM 19? Or just for 20?

[@wing-it-right]

when comparing wouldn't it be better to have it formatted the same ? I mean the Button Bar had a lot more CSS

[@filemakermagazine]

That is exactly the point. A button bar will always have more unnecessary CSS "carried along" just for the purpose of displaying a calculated value. If you swap all of your button bars, those being used to show a calculated value and not as a button per se, for the newer Layout Calc, you will be reducing what is required to render the same result. This will impact both client and web direct implementations. Granted, the XML representation of an object isn't exactly what is transferred "over the wire" but it is a method to denote the difference.

[@Rasenschneider]

Thanks 🤓

[@johnaltman4396]

One small problem we found with this feature -- if you have a field name in a layout calc and you then change the field name in Manage Database, the change does not carry over to the layout calc,.

[@filemakermagazine]

Interesting. This is likely something they will address, as is typical with most all aspects of FileMaker, schema changes will persist into all other areas of your code. A good example is Custom functions. If they reference a field, then renaming that field will "filter down" to all places where that field is referenced. I can't imagine them not fixing this. They also have an issue with errant code. Code which does not evaluate and returns the familiar "?" should not show a result in the text object - yet, it currently does. I would expect these things will get fixed.

[@siegfriedbarfuss9379]

What a sloppy implementation. Why didn’t they catch it inQA? Great video though thanks!

[@lnebw99]

Ouch

[@fleecystheking]

Button bar? I’ve been creating a calc (or a text field with calculated result) to insert it on the layout as a merge text field this whole time. Not sure how this new method is lighter.

[@filemakermagazine]

Yes, you've always been able to get something calculated on screen using either a or Unstored::calculated_merge_field, but the evaluation of the calculation has to happen somewhere. If you've been using that "additional" calculated field just to display something on screen, then you have been "dirtying" (if that's even a word) your schema. You are adding in extra calculations to co-mingle with your data fields. This comes with a cost. You will not only have more to manage, in terms of total counts of things, but potential slow downs as well because of using unstored calculations. You'll have to take my word that this improvement is quite significant when it comes to simply showing some calculated value in your UI layouts.

[@fleecystheking]

@@filemakermagazine I sincerely hope that Claris finds a way to spend less energy on buzzword heavy presentations to focus instead on the FileMaker app itself. The very fact that it’s that hard to keep a light/clean layout/schema seems retro to me. Also, 20 major version numbers on, how is it still that a succession of modal (modal!) dialog boxes constitutes the interface to almost everything in there? There’s gotta be a way to bring this app closer to 2023 conventions.

[@karlmunford7000]

Cool

[@Attila_G]

⚠ Unfortunately, these layout calculations no longer work if you rename a field. Likewise, formulas do not work if you change the Filemaker language. This is quite a big bug, which makes this new feature somewhat useless.

[@filemakermagazine]

I imagine they'll fix this. As they typically walk the hierarchy of elements when changes are made to schema.