CTreeView with 10^6 entries

[sperlis]

Hi,
Unusal? maybe! ...but I need to add about a 10^6 (one million!) nodes to a CTreeView (the CTreeCtrl, of course).
I have about 12000 root items, each with 8-10 child items. I've set .ShowWindow(SW_HIDE) and .SetRedraw(FALSE) - each apart and both together for good measure, but it is still taking a VERY long time (about 60 minute). It seems that there is a steady slowing-down of the process as it advances.
the question is: is there a way to stream line the process further? or is the tree-ctrl just not build for these things?
Is there a different approach I can take?
Is there another control I can use?
Any ideas?

thanks,
Sperlis

"Let's code fast now, so we'll have time to debug later"

[Marc G]

You could load the data on the fly when it is required. For example: initialy you only load all the root items. Only when an item is expanded you add the child nodes of that item.
Also, browse the articles at www.codeguru.com because there are some more advanced treecontrols available that perhaps support what you want.

[Rabelo]

Very unusual.... I´m thinking on the user trying to find something on this TreeView. He will get very confused, how to find something in a so big tree?
I think that it would be better if you divide them in 2 views: one a TreeView with the nodes and the other a listview to the leaves. You can also read the leaves from the file only when necessary(when the user opened a node), avoiding high memory consuption. On the ListView you can preallocate the memory, making the filling very fast.

[Ajay Vijay]

Your computer must have thousands of files. You launch Explorer and get the file by expanding the tree view. Are you in impression that Windows Expolrer "loads" each and every file in tree view??

You should retrieve the data and insert to appropriates nodes only when needed (as required by user). As far as searching is concerned, you will search the underlying data (from where you get all these nodes and items?, datbase?) and will expand upto that node [yes, this could be complex enough!]

[Syslock]

Hit Ctrl+Alt+Del to bring up your Windows Task Manager and monitor the Mem Usage of your
program while it loads. If you use up all of your RAM, then of course, everything is going
to slow down no matter what you do.

[sperlis]

Thank you all for your replies.
I tested my program again with various changes, and came to conclusion that the problem is inherent in the Tree-Control. It is just not designed to hold this sort of content volume.

I tried the VS2005 Team instrumentation tools, and confirmed that all the CPU is charged to the common controls DLL.

I'm keeping an eye out for a solution, but until then, thank you all again.

[gstercken]

I tested my program again with various changes, and came to conclusion that the problem is inherent in the Tree-Control. It is just not designed to hold this sort of content volume.

As already said by others: Long before the technical limitation (memory & performance) applies, you hit another limit: Usability. What should a user do with 12000 root items? You should probably think about another way to visualize your data. For example, the list view control has a "virtual" mode, which allows you to display very long lists of virtual data, using only a few physical items. Long linear lists are not so much a problem to the user, especially if sorting and/or filtering are provided. After the user has selected an item from that long list, you could still display the subitem hierarchy in a separate tree control.

[sperlis]

True, there is a problem of accessablity.
I've also designed (not implemented, because it is irrelavent at the moment) quick access bookmarks as well as quick-search ability to the user.
The data in the tree is very specific and whoever searches it knows what they are looking for. The other option (which we are using right now) is to save it all in a text file and search it using an editor. The advantage of the tree is the ability to collapse groups of items (of the same type) to clean up the search a bit (search specifically typed branches, for example). This is not possible in a simple text editor (no matter how un-simple it is).
The problem is I do need to keep the order of the nodes as well as allow several expanded nodes to be viewed sequencially.
Again, I wanted to come as close as I can to a text-editor type format, but in a tree control look.

[gstercken]

This is not possible in a simple text editor (no matter how un-simple it is).

Have you ever seen the folding source editor in Visual Studio 2003 / 2005? Maybe something like that would be a better approach to your situation?

[sperlis]

Yes, I've thought of it, but I wouldn't know where to start (I assumed that there isn't an available control for it, but maybe I'm wrong).
If you could point me in the right direction, I'd appreciate it.

thanks,

[gstercken]

Yes, I've thought of it, but I wouldn't know where to start (I assumed that there isn't an available control for it, but maybe I'm wrong).
If you could point me in the right direction, I'd appreciate it.

No, there's no ready-made control which does that. However, you could have a look at this.

[sperlis]

interesting, but it doesn't quite "fold" in the sense the VS code folds. I'll have to see if it can be adapted.
For my purposes, I would need to build a compound control (to allow the +/- indicators attached to the text-view) which is a bit out of my scope at the moment.

thanks again.