Virtual Multicolumn Listbox

[mje]

One of my UIs has a problem where it can chug down if you throw too much data at it. The underlying problem is formatting I'm applying to a native LabVIEW multicolumn listbox (MCLB). I'm not aware of any way to get events out of the MCLB when an item is scrolled into view, etc, so the application just blindly applies formatting to the entire list. Not a problem when I wrote the application because the data set was at most bounded to perhaps 1000 rows.

Being in R&D, we're never happy though and my colleagues who use the application started throwing data sets at it that can have something like 100 000 rows. Yeah, the UI bogs down for minutes at that point, even with UI updates being deferred etc. Simply performing hundreds of thousands of operations on the MCLB even with no UI updates takes patience.

Now ideally I'd like to have better support for the native MCLB, but for now I need to work with what I got so I figured I'd kludge together a pseudo virtual MCLB in native G-code. Here's a proof of principle:

virtual mlcb lv10.vi

If you run the VI and generate some stupidly large data sets, say 100000x8, you'll see that the render time hopefully stays constant as you scroll through the data, and with a little luck is reasonably fast.

Now if I could make a virtual tree view...

[Darren]

Looks good to me...before looking at your VI, I envisioned solving the issue just like you did...only format the visible cells. Seems like a simple enough approach that you could add a horizontal scrollbar as well with minimal effort.

[crelf]

...the UI bogs down for minutes at that point, even with UI updates being deferred etc.

Even with UI updates being deferred? I can't decide if that's possibly a bug or should be changed via a feature request...

[mje]

Even with UI updates being deferred? I can't decide if that's possibly a bug or should be changed via a feature request...

Indeed, even with the UI updates deferred. Granted these are user reports, so minutes might need to be taken with a generous dose of salt, I've not been able to try these data sets out.

Part of the problem was my fault since I never bounded the size of the data set: the application was designed around small data sets where blindly updating everything was OK. There were far more important things on the priority list than eeking out a few extra ms of performance from a UI update. Move from a few hundred to a few hundred thousand rows though and things are a different story.

These controls (trees, mclb) seem to be implemented such that once you've applied formatting to cells, the control remembers that formatting data for every cell regardless of whether that cell has data in it. I'm not arguing this shouldn't be the case, but it becomes troublesome since there seems to be no means to clear the formatting data.

Once you've applied formatting to a large number of cells, operating on that data set becomes slow. Combine that with the fact that applying each facet of formatting requires an individual operation for each cell and the number of operations required can quickly multiply. Want to set font color, style, and justification? That's four operations per cell: cell selection, apply color, apply style, apply justification. If your format cache is big, each of those operations can be slower than if the cache is small, and if you're blindly applying those instructions on a 100000x8 data set, you better have some time on your hands.

Of course I'm not implying anyone should ever do that many operations on any of these controls, again this problem arose from using the program for something outside of it's original design. The right thing to do in this case is a virtual solution like I posted above.

[crelf]

These controls (trees, mlcb) seem to be implemented such that once you've applied formatting to cells, the control remembers that formatting data for every cell regardless of whether that cell has data in it. I'm not arguing this shouldn't be the case, but it becomes troublesome since there seems to be no means to clear the formatting data.

Also true - I have a job I just delvered where I color cells based on OK/Suspect data - then, when new measurements come in, I can't assume the dataset is the same size, so I have to color an arbitrary number of cells white first, then color the OK/Suspect cells - I agree that there needs to be a method to clear formatting.

[Olivier Jourdan]

I agree that there needs to be a method to clear formatting.

You could use the following code to set all cells of mclb to the same format.

This not a "clear formatting" method, but it works and it's efficient.

Regards,

Olivier

FormatAllCells.vi

[mje]

Nice, I never knew you could do that.

[crelf]

You could use the following code to set all cells of mclb to the same format.

Ugh - I'd totally forgotten about that! Thanks Olivier

[Ravi Beniwal]

You could use the following code to set all cells of mclb to the same format.

This not a "clear formatting" method, but it works and it's efficient.

Regards,

Olivier

I've also used this and its other variants (for selecting all columns in a row etc.). It works pretty well.

Now we need a way to select all alternate (even/odd) rows/columns. That'll help when you are trying to color alternate rows/columns for ease of following a large table across/down.

[Phillip Brooks]

Here are a couple of VIs I wrote for a tool that used the MCL.

The first iterates over the MCL ItemNames to determine the max width. It looks at each cell's formatting to see if font customization have been made. Use the output to set the widths (AKA autofit width).

MCL Get Max Col Widths.vi

The second colors the rows with alternate colors.

MCL Set RowColors.vi

The assumption is that you have already deferred panel updates. These could probably be optimized, but they worked for my project.

Edited February 7, 2012 by Phillip Brooks

[Ravi Beniwal]

Hi Phillip,

This is how I've been alternate coloring the rows too. I wish there were a way to select all odd or even rows with some odd index (-3 or something). That'd be awesome (and probably faster if there were too many rows to color, even with panel update deferred)!