I remember there was some guy who was always against this auto-shrinking behavior and was not shy to tell about this on every corner so it appears that FMI sometimes listens to users. Isn't that ironical that from all flaws they decided to "fix" this one? (Which is not even a flaw, by the way.)
To the topic: I second that, the old way was much more convenient. There must be some way to resize a text label to its natural width and the old way was a good substitute. For example, I want to have a filed for SSNs and I know the data will always be like "000-00-0000". I need some way to calculate the width of such a string, so what I used to do was to take a text tool or quickly copy an existing text label, type the new mask (maybe adding a space for a little extra margin), then quickly bold/unbold it with a keyboard shortcut and viola, here's the width I wanted! I could then select the label and the field and use one of resize commands to change the field width to match the sample.
This was very fast, especially because when one lays out fields there's usually a number of labels lying around and some were just created for this very purpose of measuring width of the data. So the process normally looked so: I quickly grabbed an existing label that already had the correct font style, double-clicked it, typed new text, then bolded/unbolded it and had my sample string. This normally took like a couple of seconds.
Now I cannot bold/unbold text to shrink (or, more accurately, I normally have no idea whether it will shrink or not; some labels always shrink, even if you simply try to edit them, some never shrink and it appears that this behavior has changed slighly in 12v3, but I can't say exactly. Anyway, most labels never shrink. So the only way to get a label of correct width in v12 is to always get a text tool and type a new text. This takes much longer; besides, since mouse in v12 is very touchy, it often misinterprets a single click as a very small drag and creates a text label 1 ot 2 pixels wide. Such a label is of no use, so I had to delete it and start over. Also, all labels start in default font, so after I've typed the text I normally have to change the font and/or style either directly or by copying formatting from another label. This is far less convenient than Ctrl-dragging an existing label that already has the correct formatting.
I also want to point out that the new way is much more restricive than the old one. In v11 if you wanted to change the text style but didn't want the label to change the width, you could simply double-click it to enter text editing mode, select the text, and change its style to your heart's content; this way the label wouldn't shrink. So you could have it both ways. In v12 the new behavior is the king; the old behavior has completely disappear.
(I predict we'll be told to submit it as a feature request.)
Thank you for your great post. It is a topic that really interest me because it is true : when developing, so much time is passed on layout design ! Thus, a tiny behavior can be so much time-consuming... But we must change our techniques when needed and that's hard !
First, excuse me if i misunderstood some shadows of your last post : my english is not so well as yours. But i post here anyways because maybe i could help a little (not shure).
Next, YES, i admit, i am this kind of guy that was clearly against auto-shrink (but i never claimed it loud). Shure, it directly depends of your design techniques... Personally, the first argument was, as you said too : have to take margins ! because the "right size" doesn't exist in absolute as long as your solution will run on Mac, on PC, on iPads, on other Macs etc.. etc... the second argument is that i used A LOT the auto-align and auto-distribute objects, to save time. So what ? To facilitate this use, i generally standardised as possible all my label's and my field's height and weight (shure not always the same, depends of field type but even). Thus, auto-align and auto-distribute was "honey"... But when auto-shrink was generalised (on v11 i think), my technique was even "to trash".
Second conclusion : change behaviors of a creative tool like this can be so... touchy !!!
I know well that, since now, i didn't contributed to help... But maybe, here :• When you are sizing your objects with auto-resize commands (to smallest or largest), auto-shrink is enabled on both v11 and v12.• When you are sizing your objects precisely with Inspector's height and width fields, auto-shrink is enabled from v11 until v12.03 but disabled since v12.04.• When you are sizing your objects with mouse, auto-shrink is disabled on both v12 at contrary of v11. THAT was MY rescue...• When you just converted an fp7 file, auto-shrink is enabled on all objects whatever was the original sizing technique and that on both v12.
My final conclusion :Bug or behavior ? That is the point. But as we can see, it is really very difficult to explain the software's logic (i hope an expert maybe could?)Moreover, always changing behavior on updates is generating a lot time waste, for us, for FMI, at work, on this forum...Bye, Fred
I think a future version of Filemaker should provide both options so that we have control over whether or not the text objext shrinks to minimum dimensions. There are layout tricks that require sizing the text object larger than its minimum dimensions. We thus need an option that keeps the text block from automatically snapping down to minimum dimensions when we edit that text block.