Have you ever been limited by screen real estate in a solution? Have you ever had a field that you thought would only ever have a few words, but users have decided to write an essay? Enter dynamic text resizing in FileMaker.
Sometimes the data in a certain field can vary greatly. It is a waste of layout space to size the field to show the largest possible amount of data, but also not optimal for users not to be able to see all of their data because a field isn’t big enough. This is especially true with number fields, where FileMaker chose to display an incredibly helpful ‘?’ if the number is too long for the text field object.
Text Resizing in FileMaker
FileMaker has functions for dynamic text resizing. It also has functions that will help you get the size of a layout object. With those two bits of information you can automatically resize text to fit within a given object, making text resizing a lot easier.
Let ( [ object = "objectName" ; text = Table::text; rows = 2; padding = 12; MaxFont = 14 ; MinFont = 6; ObjectWidth = ( GetLayoutObjectAttribute ( object ; "width" ) - padding ) - padding; TextLength = Length ( text ) ; MCWidth = ObjectWidth / TextLength ; FontSize = MCWidth * 1.8 * rows ; FontSize = Case ( FontSize > MaxFont ; MaxFont ; FontSize < MinFont ; MinFont ; Int ( FontSize ) ) ]; TextSize ( text ; FontSize ) )
The problem before FileMaker 14 was, where do you put the calculation? You don’t want to put it into the field definition. The field doesn’t know what object it is being displayed in.
You could script it and put the result into a merge variable, but then you have to explicitly resize each individual object in the script and then make sure that the script runs every time either the data or the size of any of the objects is changed.
You could also do the same thing with any of the layout features that give you access to the calculation engine, for which there are quite a few, but you have the same issue with making sure the screen is refreshing when it needs to and having to code each one into the calculation.
Enter, the BUTTON BAR! Dynamically display calculated data right on the layout. All you need to do is put the calculation above in the calculation for the button bar display, where the objectName is the name of the button bar segment and the ‘text’ is whatever text you want to display. The ‘rows’ is the number of rows you want the text to wrap to. ‘Padding’ is how much padding ( in points ) the object has on its left and right side combined. Most FileMaker themes have 6 points on each side by default, unless they are a touch theme.
The calculation just divides the width of the display area by the number of characters to give the maximum average width each character can take up. It will be an average because unless it is a fixed width font, different characters will have different widths.
The real trick of the calculation is the 1.8 that the max character width is multiplied by. This modifier will need to be changed for different fonts. This multiplier was found by experimenting with different font sizes and object widths with arial on a Mac. It works fairly well, but the scaling isn’t perfect. However, the formula is extremely easy to change.
It should also be possible to take into account the object height as well as automatically change the multiplier for different fonts in different operating systems.
*This article was originally written for AppWorks, which has since joined Direct Impact Solutions. This article is intended for informative purposes only. To the best of our knowledge, this information is accurate as of the date of publication.