Tree/Lists - Updating only visible items

[mje]

So I have a tree control with hundreds of items in it. I need to update the status of these items quite regularly based off input from other controls. The problem is updating all items produces a noticeable delay which I don't like. So I implemented my update code to only work on the currently visible items:

The problem I'm left with is what happens when the user interacts with the scrollbar and new items are shown? My current idea is to implement a series of cludgy events such as mouse down, up, drag, value change (for keyboard interaction), etc...but there's got to be a better way?

[Darren]

I can't think of an event-based solution, but there is a pretty straightforward way if you don't mind polling the tree:

(If you drag this snippet to your diagram, you'll need to replace the reference control with a Tree reference so it will run)

This code will give you the tags of all visible items in the tree. If you poll this, and store the tag array in a shift register, you can compare against the previous iteration to see if it changed, and update the visible tags accordingly.

-D

[mje]

He said "poll". BURN HIM!

In all seriousness, that could work though. Or implement something like that in response to all possible events that could change what is displayed.

[Darren]

...Or implement something like that in response to all possible events that could change what is displayed.

I've gone down that path before...it's fraught with peril. Example: Grab the scrollbar (mouse down), move your mouse out of the tree bounds (mouse leave), and with your finger still down, drag the scrollbar up and down. All of a sudden, you're not getting events anymore, even though the displayed items are changing. That's why polling is the simplest solution for now...unless you want to implement your own scrollbars.

-D

[Tim_S]

So I have a tree control with hundreds of items in it. I need to update the status of these items quite regularly based off input from other controls. The problem is updating all items produces a noticeable delay which I don't like.

Are you disabling front panel updates? I find I need to disable front panel updates, make all of the treeview (or similar) changes, then enable the updates again whenever there is a large number of elements in the treeview or [multicolumn] listbox.

Tim

[mje]

Ah right. Forgot to mention that. Yes, the code is wrapped between a set of defer update property sets.

[SuperS_5]

I like the tree-polling solution.

In one project, there was a multi-column list-box, I had to update the background colours of all of the items. (couple hundred rows and several columns!) Updating them would freeze the UI until done, which was bad. So I stuck all updates to be done into the shifter, (an array) and processed a couple of these updates at a time during the timeout case. I tweaked the number of cells to process, so that the total time was not too long, but the screen was still responsive. I had some logic for searching the array to ensure I didn't have multiple updates upon the same cell. The cells that I updated were determined by which cells where visible, and if all visible were OK, then process everything else. I am not sure if this would work in your case, if you are updating the values too quickly.

[mje]

There is the possibility for update requests to pile up pretty quick. If for example a user holds down the increment/decrement button on a numeric control, dozens of value change events can get generated in a second, each of which will require an update to the tree, which seems to take on the order of a half second. I also like the idea of tinkering during timeouts.

I suppose the other way of doing things is have the tree update be entirely asynchronous. Just keep it notifier based, or something such that multiple requests don't pile up if they are generated faster than they can be consumed.

As an aside, I still can't believe tree controls are this busted. Changing UI properties for non-displayed items should be near instantaneous. If NI won't implement it, I wish they'd expose more events such that we could apply updates more intelligently. And for the non-believers, if I disable all the tree operations in the screenshot I posted above and instead blindly operate on all elements in my variant/hashtable, my updates happen in mere microseconds, so it's not my interaction with the variant or my subVI that was choking things off.

Once I get an initial code out there that works, I might tinker with dropping a custom .NET control into there or something that...works.

[ShaunR]

There is the possibility for update requests to pile up pretty quick. If for example a user holds down the increment/decrement button on a numeric control, dozens of value change events can get generated in a second, each of which will require an update to the tree, which seems to take on the order of a half second. I also like the idea of tinkering during timeouts.

I suppose the other way of doing things is have the tree update be entirely asynchronous. Just keep it notifier based, or something such that multiple requests don't pile up if they are generated faster than they can be consumed.

As an aside, I still can't believe tree controls are this busted. Changing UI properties for non-displayed items should be near instantaneous. If NI won't implement it, I wish they'd expose more events such that we could apply updates more intelligently. And for the non-believers, if I disable all the tree operations in the screenshot I posted above and instead blindly operate on all elements in my variant/hashtable, my updates happen in mere microseconds, so it's not my interaction with the variant or my subVI that was choking things off.

Once I get an initial code out there that works, I might tinker with dropping a custom .NET control into there or something that...works.

Have you tried using the .NET TreeView control.? You have access to all TreeView functions and you can add callbacks (if you need them). You can even do things like embed other controls. Not that you need to, but it just demonstrates the huge feature set. It should be a lot faster for your purposes.

I'm not a fan of .NET. But "The needs must as the Devil drives"

[Jarrod S]

Ah right. Forgot to mention that. Yes, the code is wrapped between a set of defer update property sets.

Beware using Defer FP Updates continuously in a loop, such as for each update to the tree. It will disrupt right click menus and file menus. It will completely dismiss the menu. It will do this even in other VI FPs than the one being deferred, I believe.

We have successfully delayed populating trees in terms of child items of parents that aren't expanded, but not items that are off the current scroll region. I would not recommend trying it much. On the other hand, I also wouldn't use a tree control to display anything that needs to be updated continuously. A listbox would be much more efficient because you can just use the Item Names[] property node to update a whole column of text. You can also simulate a hierarchy in a listbox by having a ring above it to select the current visible section, or perhaps a tree to the left where you can select the visible section(s).

[mje]

For things like setting the symbol and color of cells, I'd expect a list box to be about the same since you still need to always set the active cell then the color for each cell? I can give it a whirl, if it is indeed faster I can kill the tree.

[vugie]

Turn off scrollbar and make your own one out of numeric slider.