This is one of those things that is effectively a bug, in that it doesn’t behave as most users (of Axure RP) expect and want, but is technically a “misunderstood feature,” in that it works as documented.
…Or then again, maybe it is a real bug… As I set out to demonstrate this I discovered I didn’t really understand what was going on, and after a long trip down a dark rabbit hole, I managed to come out the other side with a hacked solution to your problem (skip to Page 2 to see it.) …But I still don’t understand what’s going on. On the positive side, it’s Friday and I just solved a problem that has plagued
us since the dawn of the repeater.
fit to text in a repeater.rp (203.6 KB)
There are two different "Fit to … " features that affect this issue. Here is my understanding of how this works. Each widget capable of containing text has a size property, which can be set to Default/Fixed; or “Fit to Text Height”; or “Fit to Text Width”. The latter two are dynamic such that the dimensions of the widget will change based on text content. In the editor, this is shown dynamically as you enter or paste text content. If the text content of a widget changes with one of the “Fit to …” settings, the dimensions of the widget change accordingly in the editor. Normally, this works fine and is not an issue in the browser (although fonts are rendered differently in each browser than they are in the editor so the dimensions of a widget can vary a little from the editor to the HTML in the browser.) However, in the prototype’s HTML–in the browser–this is only dynamic “once” --when the widget/page is loaded. If you change a widget’s text content dynamically in the HTML–via interaction code–the dimensions of the widget do not change again. Personally, I would love this feature, and it has been requested by users for Axure RP9 as well as in previous versions. For now, just realize this is how it works: if you set a widget to “Fit to Height” that height will only get set once, in the editor.
The repeater widget itself has a “Fit to Content in HTML” setting, which means that as the height of the content in the repeater cell changes, so does the height of the cell/row. Likewise, as the width changes so does the cell/column. Believe it or not, this is actually working correctly in your repeater (as evidenced by your “editor view” screenshot.) However, the size of the widget does not get changed in the browser, presumably because the text is getting set dynamically in the HTML via the repeater’s Item Loaded event. But, I did discover the row’s height gets set to fit the overflow text if the widget in the repeater is set to “Fit to Text Height”, and if you get the .height property of that text widget, it is reported as the height of the row–even though visually the height of the widget does not change–or more accurately, the height of the widget can decrease but not increase beyond the widget’s original height. This lead me to realize the repeater does know how tall to make each row, so if that height can be retrieved, the text widget in each row could be set based on that value. The way to find the height of the row (when the text widget is the only or at least tallest widget in the repeater) is kind of stupid, and it really shouldn’t work–but it does. In the Item Loaded event, after setting the text, get the height of that widget with the text–the value returned by [[LVAR1.height]] (where LVAR1 points to the widget) is the height of the row. So, it’s like the widget height does get changed–which makes sense, because it does get changed on the page in the editor–but that change doesn’t get shown in the browser HTML. Weirder yet, the widget height does get changed in the browser if it shrinks, but not if it grows taller than the original widget in the repeater cell. I have no idea why.
At any rate, you can read through the descriptions on Page 1, see my solution on Page 2, some shortcomings to this on Page 2b, another hack solution on Page 3, and proof this can work for “Fit to Width” as well on Page 4.