Thank you for your post.
I am able to replicate the issue with both FileMaker Pro 13 and FileMaker Pro 14 under both Mac OS X 10.11.1 and Windows 7.
I have sent your entire post to our Development and Testing teams for review. When I receive any feedback, I will let you know.
This is related to my issue here : Re: Text on Button Bar Buttons breaks over 2 lines at Font Size 11 because when I created a button from scratch, I could often get it to appear on a single line up until the moment I resized it, then it would break. But it was also only when resized manually. Resizing via selecting multiple objects and resizing all to the same wouldn't modify it.
Development has said this design was intentional starting with FileMaker Pro 12. In essence, changing the text style should not adjust the text object's width after a manual resize. Once you customize the size of the text box, FileMaker can no longer make assumptions about it anymore.
First off, please pass along my regards to our friends in development and FMI in general. I had a chance to speak with many of them at DevCon. Impressive and challenging work building out the platform.
With all due respect, there are unintended consequence of that particular FM 12 decision, and to be fair, you have not addressed what I took the time to write up in my original post.
Bug: If you change the width of a text object bounding box, the behavior of the text object changes and can not be changed back.
Let us look at this issue from a different and additional angle...
You have made cross platform development harder!
Here is how you can demonstrate this productivity issue, working on OS X.
You might want to read both of Nick Orr’s blog posts on fonts...
...and note that font width is often wider on Windows than OS X.
1. Manually create a long text string on a layout in FileMaker 13 (tested here) or FileMaker 14 (not tested here). We will call this the the flexible width version (test data: The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. )
2. Duplicate the long text string and resize the width. This text will now make the design assumptions you reported made as of FM 12. We will call this the fixed width version.
3. Resize the fixed width version using the inspector, until the text just fits.
4. Compare the results on Windows 7 (you might want to add a vertical line to the layout). The flexible width version will show all the text. The fixed version will clip the text.
This means that as soon as I touch the width of a text string, or if I am working with a pre-existing solution where the text box has been resized (and there is no way to know!), my productivity has gone down. Because the text no longer flows, it would get clipped. I have to spend time monitoring and fixing. See for yourself using the test above!
Yes, there are some use cases for fixing the width. There are others where it hurts us, as shown above.
Hopefully this is all reasonably clear.
I have forwarded your comments to Development and Testing for discussion.
This is an historic alternative behavior where FileMaker tried to guess what was the better, differently on each version.
I really hope that next versions will not break existing behavior where a manually resized text object will not auto resize anymore, just because trying to fix this issue !
But i agree with TonyWhite that we miss a visibility / a control.
I think that at this point of history, an inspector's option would be the better choice : [X] Resize to fit.
I want to add my support for this issue report. It drives me nuts.
But first, Tony, a work-around that I have been using for a long time is to end every text object with a space. I found that was sufficient to accommodate the difference is font metrics between Mac and Windows. On iOS many fonts are wider, and text may need two trailing spaces to make up the difference.
Second, Tony, I haven't been to Devcon nor have I met these vaunted engineers so I'm inclined to form extremely unfavourable opinions of them. I presume that they are hairy and misshapen.
Now, back on topic, I understand that, in principle, when I have created and modified an object, my design decisions should be respected and preserved. However, fonts are handled differently on different OS. The FMI engineers have recognised that and developed a "magic spell" for accommodating these differences. Why would they do that? Why put any effort at all into that job unless it had real and obvious value?
On any layout there will be a mix of enchanted text objects and "plain" text objects. Yet we have no way to know which text objects are still blessed by magic and which ones have lost their spell. There is no discussion or documentation about the "magic spell" that is cast, so we don't know that our decision to resize the text object will destroy the magic. Indeed, we may not intend to change the object size, it may happen inadvertently. However, the spell has been broken and no amount of crying and pleading our innocence will change that. Nor do we have any way to repair it. We can only start again, from scratch and replace it.
What they are saying is that the little magic spell that they cast on new text objects is broken when we adjust the text object width and that they are duty bound to respect our decision. Far be it for them to presume to know better than us. Very high and mighty. However, they are the only ones with the magic wand and they don't allow us to use it. So, on the one hand they say that they cannot make a decision for us. On the other hand they do not allow us to make the decision ourselves. They have obviously put a lot of thought into this and the decision that the user should be the one to decide is correct. Now, if only it had occurred to any of them to provide the user with the means to make the decision we would be happy.
What I understand is that FileMaker software supports text resizing to accommodate differences in font metrics on different OS and that newly created text objects come into the world with this ability. However, any change to the size of the object will change that. So, there is obviously a flag of some sort that is used to determine which text objects remain privileged and which do not.
Why can't we have access to that flag as an option in the Position tab. After resizing a text object we could decide whether we want the text object to retain it's magic or whether our purpose is really to box the text in a cage too small for it.