From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Tree control refresh too slow when large quantity items inside

Hello,

Tree control refresh too slow when large quantity items inside.
Does anyone have method to accelerate this processing?

Thanks in advance!

Zhanzhong
0 Kudos
Message 1 of 10
(4,773 Views)
Hello Zhanzhong,

Try taking a look at the tree sorting shipping example located at C:\Program Files\National Instruments\CVI*.*\samples\userint\treesort.prj.

This example uses multiple items inside the tree control and doesn't seem to have decreased performance on the user interface. I don't know if the amount of entries in the tree is of the same order of magnitude as your application, but I would take a look at the code and see if there are any conceptual differences between the two.

Thanks!

Wendy L
National Instruments
0 Kudos
Message 2 of 10
(4,767 Views)
Set the VI:Panel:DeferPanelUpdates attribute to TRUE while updating the tree. Then set it back to FALSE.
0 Kudos
Message 3 of 10
(4,767 Views)
The DeferPanelUpdates attribute refers to LabVIEW. For CVI, I would also suggest explicitly calling the ProcessDrawEvents() when you want to refresh the tree control.


Wendy L.
National Instruments
0 Kudos
Message 4 of 10
(4,767 Views)
Could you elaborate what you mean by too slow when processing? How many items do you have? What type of action is slow? Are you interacting with in with a keyboard or mouse?
Do you have an example i could use? I tested this with 10000 items in the tree and it seemed to behave ok.

Bilal Durrani
NI
Bilal Durrani
NI
0 Kudos
Message 5 of 10
(4,767 Views)
Sorry for reply so late.
I test with 1,000,000 items within tree control, it seems it never ends.
With 100,000 items it is also slow.
my code is below:

char tag[256];
char label[256];
int index;

ClearListCtrl(panelhandle, P_TREE);
index = 0;
for(int i = 0; i<1000; i++)
{
for (int j=0; j<1000; j++)
{
sprintf(label, "%d", i*200+j);
index = InsertTreeItem(ph_panelhandle, P_TREE, VAL_SIBLING, index, VAL_LAST,
label, "", tag, -1);
}
}
0 Kudos
Message 6 of 10
(4,641 Views)
Hello yyh777,

I am able to reproduce the behavior you are seeing, but maybe it is important to come at this problem from another angle. Do you need to add 1 million items to a tree control? You're only going to be able to view a small percentage of the items at one time. Maybe it would be more tangible if you logged the data to a file if you need to track that much information, and only log a subset of data at one time to the tree control.

Thanks.
0 Kudos
Message 7 of 10
(4,616 Views)
Hello, Wendy L,

I agree that in most cases I do not neeed to add so many items to TreeCtrl. But in my project the tree ctrl get information form a XML file and display all items hierarchy. So, have many items should be inserted into is no decided by the code but the XML file loaded by a custom who uses my software to load it.
I think NI should update tree ctrl in several points:

1, tree ctrl can be set max. number items before using
2, tree ctrl should be refreshed much faster by providing some functions to prohibit refreshing before all items are filled, just like ATTR_REFRESH_GRAPH for graph control.

regards,

yyh777
0 Kudos
Message 8 of 10
(4,588 Views)
I also experienced this problem, and found it especially noticable when the tree had children that were expanded. I used a bit of a kludge to fix this, but here is what I did.

Right before loading the data into the tree, I use SetCtrlAttribute with the ATTR_VISIBLE property to make the control invisible. When the data has been loaded into the tree I once again use SetCtrlAttribute to set the ATTR_VISIBLE property back to visible.

I don't know what type of requirements your software has, nor do I know how long it would actually take your system to physically load 1,000,000 items. However if it doesn't take an extended time to process your data I have found that the transition from visible to invisible and back to visible again isn't noticeable at all.
0 Kudos
Message 9 of 10
(4,577 Views)
Hello, DaveC,

I also used your way (ATTR_VISIBLE form 0 to 1 and back) to speed up displaying, but from my feeling(I did not set a timer to record the time cost), it does not help much (if it helps). And I agree on your point that the displying speed strongly depends on not only the amount but also on the structure, more subtrees more time is needed.

Regards!

yyh777
0 Kudos
Message 10 of 10
(4,556 Views)