LabVIEW
Tables where the Active Cell:Cell Size:Height is set are slow to scroll?
Solved!
@LLindenbauer wrote:Am I correct in my assessment? If Yes, is there a way to deal with it when I really want to set a large number of row sizes differently?
Why do you need scrolling to be (really) fast?
Is it so slow that it stops user interaction? If you're automatically updating, and if that's too slow, I'd perform the update in a 2nd loop. Send the updates in a 1 element queue and lossy enqueue the updates. That will only execute the last update...
Search LabVIEW like a graph!
wiebe@CARYA wrote:
@LLindenbauer wrote:Am I correct in my assessment? If Yes, is there a way to deal with it when I really want to set a large number of row sizes differently?
Why do you need scrolling to be (really) fast?
In essence: Because it is a requirement. Even if it were not, the user experience is noticeably degraded when one perceive the program to be struggling to just show the next line in a table. In deployed code, scrolling one tick takes upwards to a second. I would not appreciate a spreadsheet program taking this long when the content is not complex.
Is it so slow that it stops user interaction? If you're automatically updating, and if that's too slow, I'd perform the update in a 2nd loop. Send the updates in a 1 element queue and lossy enqueue the updates. That will only execute the last update...
I already have such a setup in my main application for exactly that reason. In this sense, blocking the GUI is not the primary issue, but the immediacy of visual feedback. The slow scrolling is also present in the editor when the VI is not running. The issue is within the table itself, not the code running around it - it's just easier to quantify that way.
When no line heights are changed, scrolling through the table takes constant time
but the scaling is linear when some (or all) lines are formatted
This is my benchmark on the development machine. At the bottom of the table, scrolling takes place at about 7 fps. In production, it is much slower than that.
As an aside, something that I just stumbled upon while testing:
When setting the row height for [-2, -2] and then manually, in the editor, changing the height of specific rows, these rows will keep their height, even when running the code to set the row height for [-2, -2] again - except when the [-2, -2] height was changed to some other value in between. I believe that this behaviour is not entirely covered by the manual.
I guess you're lucky to get linear increment. Often the listbox shows exponential increment 😁.
I think I'd try to make a dummy listbox and scrollbar. Then catch the scrollbar events, calculate what needs to be in the listbox, and put it there starting at 0,0.. When done right, I think this will appear to the user as if (s)he's scrolling through the data.
Updates might be slow, but at least it will be constant. Question is if it's fast enough...
@LLindenbauer wrote:If I may ask: What would be an advantage of using the listbox over a table? When would one choose one over the other?
I didn't gave that much though.
They're just different, most notably the values. A table as the strings as value, a listbox the selected value(s).
IIRC, all problems with (non-linear) slow updating apply to both.
If the user can edit the values, a table makes more sense. Although even for a table it's hard tune the UX, so eventually neither a listbox nor a table work well 😊.
