none
C# TreeView Maximum Nodes

    Question

  • What is the maximum number of nodes a TreeView can have and still allow ALL nodes to be scrolled and viewed in the treeview? 
    Thursday, July 24, 2008 10:18 PM

All replies

  • Yes, the Windows (not C#) TreeView has limitations on the number of nodes.  Given the fact that you're asking, you probably already know the answer.  Raymond Chang's answer to questions like that is: "if you need to know, you are doing something wrong".  The particular wrongness here is that you should never design a UI where the user has to scroll through thousands upon thousands of nodes.  Just creating the tree iwould make the user reach for Ctrl+Alt+Del.
    Hans Passant.
    Thursday, July 24, 2008 11:21 PM
  • I have a treeview that is connected to my major database. It is not connected via a DataSource, that would have made in very inflexible. I make needed connection on demand. The treeView begins when the form is opened with just 33 nodes. They represent major categories of the things I am dealing with: family, office, money, home necessities, hardware, etc. All other nodes and potentially there could be close to 200,000 of them are children and grandchildren of those root nodes of the first level. They are hanging on short or longer branches. When I do a search thru my DB the system programmatically generates new nodes and expands the treeview in a particular direction and I always see the full window. I could have programmatically calculated how many nodes my sessions reach but I will never do it unless there is a problem. So far I haven't run into one.

    I like the nobugz' answer.
    AlexB
    Friday, July 25, 2008 1:58 AM
  • There are situations in which a treeview with numerous nodes actually makes perfect sense.  It depends on the nesting (or depth)and data organization.  True, if you have thousands and thousands of child nodes under the same parent node then that is really data that cannot be realisticly analyzed.  I have seen applications that let the treeview be the cache of all data, but it only displays portions of the data based on filtering.  Please do not assume all will be viewed at the same time.  In this arrangement, using the treeview hashing, is very practical.  Just my opinion.

    The question had two parts.  The first part was how many nodes can be added to the treeview, and the second part was how many can be scrolled and viewed.  I am finding these two are very different.  I can add many nodes to a treeview but there appears to be a cut off point on what can be viewed and scrolled.  It also appears to depend on node depth.  That is, add 100000 child nodes to a parent node and the treeview can actually collect the nodes, but it will not allow you to scroll them.  Break this up into bulks of 10000 with 10 parent nodes and the treeview once again allows all to be added, but this time all child nodes can be viewed under each parent.

    So I think the answer to the first part of the question, concerning how many nodes can be added, is actually a limitation of memory only.  The second part, about viewing all the child nodes under a parent node, appears to have a very real cut off limit.  Does anyone know the cutoff limit?

    Friday, July 25, 2008 5:51 PM
  • I think you are trying to describe a dynamic situation which is in fact static. As I said, I have perhaps over 200,000 potential items to display but some of them never see the light and even if I accidentally come across them I tend to delete them because they are obsolete. Sometimes I delete whole branches with a hundred items or so because that subject does not interest me anymore.

    No matter where I position my "scope:" close to the root or at distant branches I always see only 20 items displayed. They may be on different levels, serrated but at any given time I see only 20. It is aactually plenty. In fact sometimes my system inserts special nodes that indicate groupings like: URLS, etc. It  means that the number 20 is further reduced by 2 or 3.

    I have no trouble navigating from node to node because of the embedded system that allows me to jump quickly from one node to another if a search produced a set of values.

    Long time ago I measure levels and found that at that time I had the depth of stories. It was at the time when I first debugged this system yet in a different language altogether.

    I think your impression that there is a limit on the number of nodes in the treeView is incorrect. Assuming the RAM is limitless, what you may see is the performance bottleneck. When you have so many nodes the system has to inventory them all to show the portion you want. By the time it is ready you perhaps lost your patience and creashed the app. It is a CPU thing, paging, etc, in essense a bad design.


    AlexB
    Friday, July 25, 2008 6:23 PM
  • I do not understand where you think I have an impression of the maximum number of nodes.  See post before this where I state this is based on memory only w/r toadding.  As far as viewing the nodes, write a simple Application to dump some nodes to the treeview and you will see that you CANNOT scroll all of them although you can add as many as you like (until memory is exhausted.)  I am seeing roughly 35000 nodes can be scrolled though you may have added many more.  So yes THERE IS a maximum you can scroll and view at once under the same node.  Again, I am not advocating there is a design to show this many nodes under a single parent node;  I only need to know the bounds.

    As far as static versus dynamic data.  Not important.  I can describe different scenarios where the data is static or dynamic, and still need the ability to store many nodes at once.
    Friday, July 25, 2008 6:47 PM
  •  As far as viewing the nodes, write a simple Application to dump some nodes to the treeview and you will see that you CANNOT scroll all of them

    That's interesting. You are suggesting to me to write a "simple application" but I do have a fairly complex one that does exactly that and much, much, more and I am telling you that I can scroll and see eventually all nodes that have been displayed, all of them. There is no limitation at all.
    AlexB
    Friday, July 25, 2008 7:45 PM
  • Completely disagree.  Specifically, add 100,000 nodes all under the same the root node of your tree view.  The treeview will collect all 100,000 nodes under the root nood just fine.  When I view the root nodes contents in my treeview, my scroll stops at roughly 40000.  I cannot see the remaining nodes.

    Curious if you can do that.  If you can, there is something wrong with my environment and I will dig further.  If you can't then there is indeed a limit to what can be viewed / scrolled under a parent node.
    Friday, July 25, 2008 8:12 PM
  • I have exactly 33 root nodes. By the root node I mean treeView1.Nodes[ jj ] - the first generation nodes attached to the treeView. Why in the world would you hang 100,000 nodes on a single root node? Perhaps this is where your problem is.

    My approach is different. I know that I can perhaps hang 100,000 nodes on my treeView but why in the world would I do it?

    I do searches and every time the search ends in some number of records those records are displayed. This is all I care about.
    AlexB
    Friday, July 25, 2008 11:05 PM
  • You are right.  You can add as many as you want, but you can only scroll up to about 65,000 nodes.  Anything beyond that will not be displayed in the tree.  I don't know why there is such a limit in .NET.
    Tuesday, September 16, 2008 9:20 PM
  • I have exactly 33 root nodes. By the root node I mean treeView1.Nodes[ jj ] - the first generation nodes attached to the treeView. Why in the world would you hang 100,000 nodes on a single root node? Perhaps this is where your problem is.

    My approach is different. I know that I can perhaps hang 100,000 nodes on my treeView but why in the world would I do it?

    I believe you are missing the point of the question here. We can agree that on a design standpoint adding so many subnodes to the same root is not elegant. The question is What is the max number of nodes (if there is any) and what is the feedback that the .NET reports when that number is reached.

    As a matter of fact, I've tried the test proposed here by Henrici and it appears that if I add 100000 nodes to the treeview, the .NET adds them without any problems, but only shows roughly 35000 of them. It is not a memory consumption issue as free memory is available, but the framework doesn't generate any error which one would expect by a well designed sw platform.

    By the way, my application shows a list of tables in a database. In some cases the number of tables can be huge, but using a treeview for this job doesn't seem so unusual (see MS SQL Server console).
    Monday, February 15, 2010 9:44 AM
  • From some tests I made, it looks like some values are stored in 16 bits. I think the index of the selected node and of the first displayed node are in 16 bits.

    Monday, February 15, 2010 10:55 AM
  • There you go, 2^15 = 32768, that is likely the limit.

    Sounds like even though todays processors are 64 bit, the treeview, instead of taking advantage of it,

    may be inheriting some old 16bit concepts from SDK.

    Why would an indexing variable be any smaller the the CPU preferred integer size?

    You could try adding the 32768 nodes to a single root node, with the node name set to the index, get the exact count.

    That would be your upper limit you are seeking.

    • Proposed as answer by Yash Shukla Thursday, December 23, 2010 6:45 AM
    Friday, August 20, 2010 2:47 PM