A neat trick for dealing with Large Table Data

[swatts]

Hello Lovelies,

Today I'm going to talk about LabVIEW for a change, this here is a clever lil trick to make your fat tables etc dynamic and responsive.

Problem

I've got masses of data and I want to put it in a Table or List box. I want to colour in the background colour for the cells if they are within the ROI (region of interest). I want to switch in an out sub-sets of the data and summary info. Our example table here has 6100 readings in 19 channels, that's 115900 cells not excluding headers etc.

LabVIEW can handle this, but it's beginning to make my laptop grunt a bit. Here's the easiest and gruntiest way to do it. Load the multi-column listbox with all the data and check the ROI set the cell colours accordingly. This is slow and unpleasant.

Next use Defer Panel Updates... This speeds things up a lot!

But it's still a but clunky and is sucking a lot of CPU, time to roll up our sleeves and get tricksy on this!

Here's the thing with UIs, the user is only looking at a finite amount of data at a time...

A graph is only x pixels wide and a table is only x columns by y rows. In the case of the one in this project it is only 39 rows by 19 columns (I'm going to leave columns as is because I'm lazy.

If we could fool the user into thinking that they are seeing an entire data-set when they are only seeing 0.6% of it we'll be winning and grinning.

The first thing we will need for our sleight of hand is a scrollbar control and we then need to tell it some important info.

I've shifted the scrollbar over so you can see my little white lie.

The page size tells it the amount of increments in a page (in our case rows=39). When you click on the slider part it will go up and down a page worth (or 39 rows).

The increment property is set to 1 and this tells it that when you press the Up,Down arrows it goes up down 1/39 per press.

These are all fixed on start-up, leaving only one thing left, the maximum value for the scrollbar and this is dynamic depending on the size of the record set loaded. In this case it will be 6100 or the number of rows.

You should now check that you scrollbar acts similarly to the fully loaded table scrollbar.

You may have noticed that I use a constant vi to set the page size, this is because this number is important and I only want it to change in one place.

Now all I need to do is select blocks of 39 rows based on the scrollbar number. Nice and easy.

The next technique is very useful for colouring an entire row of a table.

Notice that I have set column to -2, this colours the entire row (pink or white), also notice I then set it to -1, this is just setting the row header to grey again.

I use the row header to decide the Cell BackGround colours, again pretty simple.. If it's a character it's white, if it's the word "Data" it's grey, if it's a digit it's pink or white depending on whether it's in the ROI or not. 

Very responsive and CPU usage is now negligible.

How very splendid.

Once again thank-you to James Powell for demoing this many years back at CSLUG, it's saved my ass a few times now.

Lots of love

Steve

[drjdpowell]

I stole the idea from mje on LAVA: Virtual-multicolumn-listbox

[Dhakkan]

It is indeed a neat trick. One that's also commonly used in web pages by web front-end development gurus.

And unfortunately, a trick... (Referring to how the setup of the second scroll bar becomes a fair bit of effort to customize. I've had enough trouble manipulating the 'up' and 'down' triangles to maintain visual congruity of the UI.)

While LabVIEW's graphical programming certainly provides for efficiencies (courtesy of Darren Nattinger's tips); front-end UI manipulation seems to be quite another story. I wonder what you and the LabVIEW community at large feel about this. (Maybe another blog topic, Steve?)

[swatts]

I have some ideas..

I don't know if anyone is the same as me, but I struggle to think of improvements to the tool I use.  I think this is because I'm focused on the problem I'm trying to solve.

I have a radical idea about separating control and indicator FPs with overlays and pass-thru's. I think the LabVIEW team would cry if I talked more about it.

[Dhakkan]

 Message received loud and clear! <whisper>We've had to 'adjust' some VI Analyzer settings.</whisper>

[Intaris]

I do something similar whenever I need to give the impression of displaying data in "large" arrays on the FP of an FPGA VI (for interactive execution).  This can consist of hundreds or thousands of data which becomes rapidly prohibitive on FPGA targets.

I store the actual data in BRAM, but only ever show a sub-set (and this require far less Registers and LUTs than I otherwise would.

Feels just like the real thing.

[swatts]

It's like when I hide the ball instead of throwing it for my dogs.

The brain is slower than we expect and it's useful to know.

[FireGiant]

I will have to keep this in mind. A really cleaver approach to avoid the inclination I know I'm going to have to brute force stuff like this.

[swatts]

Welcome to the Blog FireGiant.

It radically changes the responsiveness of your UI and is surprisingly simple to implement.

[FireGiant]

Thank you I appreciate the welcome. I am just over a year into my NI experience so I'm actually really excited to go digging through your blog index to see what I can pick up.

[swatts]

Hopefully I won't put you off!