Autosizing Row Height for Tables requires Value Property Node

[LLindenbauer]

Dear All!

I just spent some time debugging an issue where the line height in one of my tables did not refresh correctly to the content. Here is what I have learned:

The Autosizing Row Height Function (https://zone.ni.com/reference/en-XX/help/371361R-01/lvprop/multcollst_autosiz_rowhght/) needs to be set using a value property node so that the autosizing can take effect (see attached VI snippet). 

Best Regards

[FireFist-Redhawk]

Something is happening with the timing of the property node that enables the auto row and the update of the tables. It does make sense that once you turn on auto height from off, an update to the heights won't actually happen unless the current value contains a multi-line string somewhere. I'll be honest in that once we start talking wayyy under the hood of LV, I'm not too confident.

That being said, the main thing making the code behave erratically is the floating Waits. If you make sure there's sufficient time on both sides of the table update (sequence frame) in the top two cases, they behave the same as the bottom. See attached and note the Stall Data Flows in series with the error wires. My guess is that the bottom one works already because the value property node causes a change to UI thread (not confident) and that causes there to be sufficient time on both sides of the sequence frame already. And the thing making the top two sometimes fail/succeed is that the table's property changed before LV registered that the value had changed, but sometimes the wait happened in the middle of that.

Spoiler

[LLindenbauer]

My guess at the underlying interaction would be

• The Autosizing checks if it was turned off and performs a resize on the values currently displayed.
• Directly wiring to the terminal does not change the displayed value, which is scheduled for later.
• This would then produce a race condition where the Autosize may act before the value update is propagated.
• By using the value propery, an update is forced, eliminating the race condition.

My prediction based on that guess would be that for sufficiently small delays on a sufficiently fast computer, the race condition would reemerge.

[altenbach]

As the quoted help says, it will typically only react to user input, not programmatic updates, but auto-sizing can be forced by writing a value property followed by togging the autosize property off, then on..

QUOTE: "This property affects only user input. If you use the Value property to set the multicolumn listbox strings, the rows do not automatically resize. To resize the rows, set this property to FALSE and then set it back to TRUE."

Thus I would probably do something as follows:

(Can you explain the bewildering amount of sequence structures and parallel waits in your example?)

[LLindenbauer]

---

(Can you explain the bewildering amount of sequence structures and parallel waits in your example?)

---

Because that is how I interpreted the quoted help page: Resizing only happens when toggled from off to on.

I thought that this construct - wiring a data dependency through any structure containing a connector or local variable -

would ensure that the value for that connector (in this case, "Sometimes Not") is set before the property node is executed. Am I wrong here?

[altenbach]

The help does not mention the scenario where the table is an indicator, just that it will only auto-resize on direct user input, i.e. if the table is a control.

It however clearly states that resizing can be triggered by writing to a value property followed by toggling the property first off, then on. (It does not say from off to on, as you interpreted). If this is done as in my simple example, everything works as expected, so I would stick with that. 🙂