LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Adding a single line to a multicolumn listbox?

Hi Community,

 

I have a multicolumn listbox which tens of thousands of lines where each line is color coded and represent a cycle with a pass/fail status. The only way I have found to add lines to a multicolumn listbox is to read its ItemNames property which is a 2D array of strings, add the new line to the 2D array and then write then new array back to the ItemNames property.

 

The problem is that after couple thousands of lines this get more and more slow.

 

Is there any way to speed this process up, maybe by adding the line to the listbox in a different way?

 

thx.

0 Kudos
Message 1 of 8
(4,562 Views)

I haven't played much with ListBoxes, but it sounds like your problem is related to Array Processing.  If your initial Listbox was 10000 x 3, then to add one more, LabVIEW would probably need to allocate 10001 x 3, copy, add the new data, then assign the new Array of 10001 x 3 to the Listbox (not sur e what it would do with the initial array ...).

 

Another "system" that seems to be able to handle 2D arrays of data, including allowing color-coding of the rows and adding (and subtracting) rows fairly well is Excel.  For this particular task, does it make sense to let Excel "be the Listbox"?  I'll admit I've thought about this only from the standpoint of viewing and presenting the data, including adding on a new row (at the end) -- I haven't given as much thought to selecting a row.  You'd probably want LabVIEW to have a slider that would enable you to specify the row, would need some "magic" to get Excel to center its view on that row, and then read/write the row (this last part is easy -- I've not (yet) tried to program "Show me Row X in the Excel Workbook", but I'm hopeful that this is doable).

 

Bob (When Life Hands You a Lemon, Make Lemonade) Schor

0 Kudos
Message 2 of 8
(4,542 Views)

Listboxes don't handle large numbers of items well (particularly not when you change properties). I'm ignoring for the moment of whether a MCLB with that many lines is a good solution in the first place (I would say usually not, but maybe in your case yes) and instead I would suggest that you separate the data from the display.

 

Keep the relevant data stored somewhere else (for instance in a cluster in a shift register). This can include an array for the data, an array for the row colors, etc. Update that data when needed. Hide the MCLB's scrollbar and drop a separate scrollbar control and set it to have the correct numbers. Use the value change event on the scrollbar (and properties like Number of Rows) to decide which section of the data to show in the MCLB. This will significantly improve your performance and will also allow you to provide alternate UIs to decide which data to show (e.g. like simply typing the row number or searching for a test name).

 

Beyond that, you should also make sure you use Defer Panel Updates the -2 value on the ActiveCell property (read the help for the property).


___________________
Try to take over the world!
0 Kudos
Message 3 of 8
(4,530 Views)

Listboxes are typically for the User Interface.  Most users cannot easily comprehend or manage tens of thousand of data elements. Perhaps you should re-think what you are trying to do.  How does the user find the relevant data? What does he do with it afterwards? 

 

This sounds like data that might be better stored in a database with LabVIEW being a user interface to small segments of the data.

 

If you do need to keep all the data in the listbox, try preallocating an array which is larger than the largest dataset you will have. Then use Replace Array Subset to update the array.  This avoids the memory re-allocation issue Bob Schor described. The listbox display itself might still be slow. I never tried to use one with that much data.

 

Lynn

0 Kudos
Message 4 of 8
(4,528 Views)
Think about how a search engine handles it when you make a common search. Breakup the huge mass of data into pages. Then provide a mechanism for searching and filtering the underlying data before display.

Mike...

PS: you really need a database.

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 5 of 8
(4,502 Views)

Tst's idea is really good, keep the data in a shift register and show only 20 lines (or however big the listbox is) at a time, with a separate scrollbar to control which 20 are shown.

It'll be lighting fast and not too hard to implement.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 8
(4,454 Views)

The Listbox, and Multicolumn listbox controls got many UI performance improvements in 2013, what version are you using?

 

https://lavag.org/topic/17009-labview-2013-favorite-features-and-improvements/

 

But even if you are on an old version there are many tricks to making the UI more responsive, like using defer panel updates, and virtual multicolumn listboxes.

 

https://lavag.org/topic/15289-virtual-multicolumn-listbox/

Message 7 of 8
(4,434 Views)

Thanks to all for your suggestions... We ended up showing only the last couple dozen of cycles and let the user mine it out from the database if he/she is really interested.

0 Kudos
Message 8 of 8
(4,398 Views)