TreeView That Allows More Than 32,765 Nodes?

[PeteCresswell]

Has anybody found a (third party?) TreeView that allows more than
32,765 nodes - and which they like?

 

[Tom van Stiphout]

On Mon, 22 Jun 2009 06:01:32 -0700 (PDT), PeteCresswell

I just checked the Infragistics treeview that I like, but it doesn't
fit the bill.
So let's think about this differently: just like it doesn't make much
sense to add 32K items to a dropdown, perhaps the same applies for a
treeview. It takes a long time to load, and the user is never going to
be able to visit all this info (at 1 second per node it would take 9
hours!).
Another approach would be to do a virtual tree: it is initially
populated with only the first-level nodes. Only if the user drills in
are the needed nodes quickly added (one level at a time). This would
likely avoid you ever getting up to 32K nodes.

-Tom.
Microsoft Access MVP

 

[Tom van Stiphout]

On Mon, 22 Jun 2009 06:01:32 -0700 (PDT), PeteCresswell

Another option: use an HTML control. Surely it can be (almost)
unlimited. Would require a fair understanding of the DOM and
client-side scripting.

-Tom.
Microsoft Access MVP

 

[PeteCresswell]

So let's think about this differently: just like it doesn't make much
sense to add 32K items to a dropdown...

Before loading said tree, I was estimating the size of the loaded tree
based on the input recordset - and issuing a warning if the number of
nodes was approaching the limit.

Turned out that my estimating code was way pessimistic - mainly bc it
was double-counting something in a loop.

Your observation is right on the money time-wise..... this tree was
actually only 6,000+ nodes and the estimate was 29,000.

Another approach would be to do a virtual tree: it is initially
populated with only the first-level nodes. Only if the user drills in
are the needed nodes quickly added (one level at a time). This would
likely avoid you ever getting up to 32K nodes.

I like this a *lot*.... and will try to implement it.

With 6,000 nodes, the time to load the tree is beyond what I (as a
closet type A) would consider acceptable.

Even with fewer nodes (the user has options.... 6,000 is the result of
the user choosing "All") , faster still has tb better.