Display a huge list of elements: Tree control, ActiveX or something else that can be filtered?

[Christ0phe]

Hello all,

My application allows the user to select parameters out of a huge list of 30.000+ parameters. Until now I have managed this by initializing a huge tree control structure that allows the user to navigate through an intuitive hierarchy until he reaches the final tag he wants to select (see Capture_TreeControl_Example.PNG). The drawback of this method is the initialization time of the tree (more than 15 minutes!).

I am thinking of using another method to achieve such selection process i.e. possibly the one that I show in the other attachment (Capture_Qlik_Example.PNG) i.e. no structure at all (flatten the list) and just typing first letters of the parameters, using wild cards would dynamically filter the view.

Has anyone found a solution to implement such control in Labview?

Thank you very much for your feedbacks and ideas

Christophe

[LucianM]

How about listboxes? I used them when I had that many items to display to the user. Performance of the listbox is much better than the tree.

Child items can be shown in another listboxes and be updated only when user selects a new item in the main listbox. Filtering can be done using a string control and Search/Split String in a For Loop.

[mcduff]

More work, but rather than initializing the whole tree at once, initialize the first hundred or so parent items; when a user scrolls down, reinitialize the tree with the next hundreds of items, etc.

mcduff

[Sebastian.Weber]

You didn't show your code... 15min ist really, really long, and I guess your code is not optimal.

• Do not insert one line by one into the tree. Use AddMultipleItemsToEnd instead, if you want to add all items at once. Note that this function does not use parent tags, but indention levels. Hoever, for 30.000 lines, this could still take a while, and I'd go another way:
• Only add the top level items. For each item which has children, append a single dummy child, and close the item. This way, you get all the '+' in front of the items. When an item is opened by the user (Event structure), check if it has a dummy as child. If yes, remove that dummy child, and append all real children. Again, do not add grand-children, but dummys. This way, only items the user opens are inserted (plus some dummys), but unless they navigate everywhere, it will be much less than 30.000
• Trees are notoriously slow. Set DeferPanelUpdates=true before and =false after adding multiple elements.

[Christ0phe]

Hello and thank you all for your feedbacks,

To LucianM: yes this would work better but having two or three listboxes side by side is something I do not like.

To mcduff: this is the solution that we had in mind in case no other magical object would be integrable into our Labview code

To Sebastian: yes we are already using AddMultipleItemsToEnd and DeferPanelUpdates to true. Your proposal to populate the tree on demand rather than in the initialization phase is similar to mcduff’s proposal.

But the other part of my question was: how is it possible that nobody has ever integrated an object that we would fill with flattened string, the object being then filterable the same way we do it in many application like Excel, QlikView, even a simple Java Script does the trick (https://www.w3schools.com/howto/howto_js_filter_lists.asp )

Thank you again for your feedback

Christophe

[Mark_Yedinak]

We ran into this issue years ago. Our trees were not quite as large as yours, but were still about 15K entries. Yes, updating that tree was unbearably slow and was definitely timed in minutes.

We solved this issue by implementing a tree class. Our tree class contained a flattened version of the data and the tree reference. Depending on what operations were being done, we would either update the tree directly or work on the flattened data and then update the tree. In any case, we always kept both copies of the tree in sync. We ultimately achieved very good performance. I don't think I can release this code however. I am simply saying it is quite doable.

[Christ0phe]

I am just wondering if I will not end up with something that I have just quickly built in the attached VI...

This has the advantage of removing all the initialization time and incorporates the powerful 'Match Pattern' style of filtering...

[mcduff]

I haven't made any timings, but the following may be faster. In your method you are searching one by one, the following may be faster, you will have to test. 2012 version attached.

[BertMcMahan]

@mcduff, where'd you get that Match 1D String Array function? Is it in the pallete somewhere or is it a Hidden Gem?

[mcduff]

---

@BertMcMahan

---

Hidden Gems.

Really a useful function, should be on the palette.

mcduff