Win32 TreeView Scrolling > 65k nodes

[Jobizzu]

Hi there,

I'm writing an application where I use a Win32 TreeView to display some data. I've noticed that if the number of nodes in the tree is greater than 65k, then the scrollbar does not properly show all of the nodes...it displays what appears to be (n % 65535) nodes. For example, if I add 66000 nodes to the tree, the scrollbars will only show the first 465 nodes and will not scroll beyond that.

Has anyone seen this behavior before? Not sure how to handle this problem. This is straight Win32 C++, not .Net/C#

Thanks!

[3hM2Nwbp]

Sinisterly sounds like an overflow to me. I'll wager a guess that good old Microsoft used a 16 bit data type to hold the number of elements in their tree view implementation.

[Jobizzu]

I suspect this to be the case as well. The fact that it's occurring precisely at 65k suggests 16-bit issues. :(

I was hoping maybe someone out there had been able to find a workaround for this problem...surely there are others out there that have needed to hold more than 65k nodes in their trees? I can't be the only one...haha.

[3hM2Nwbp]

I would think that it would be possible for you to roll your own 'Paged Tree View' control if you can't find any useful information from Microsoft about a workaround for this.

I would check out Microsoft's documentation about this before rolling your own though.

[andywestken]

This might be a problem relating to the scollbar, rather than the tree itself. From MSDN's entry for "SetScrollPos Function"

Because the messages that indicate scroll bar position, WM_HSCROLL and WM_VSCROLL, are limited to 16 bits of position data, applications that rely solely on those messages for position data have a practical maximum value of 65,535 for the SetScrollPos function's nPos parameter.

[Jobizzu]

Hmm, you might be right about the scrollbar. I did a little more experimenting and discovered that the tree can actually hold more than 65k nodes just fine. But as soon as more than 65k are visible (i.e. enough nodes are expanded to show more than 65k) that's when the scrollbars get out of whack. If you collapse the nodes to less than 65k the scrollbars fix themselves.

I've read about the scrollbar limitations before, and in the same MSDN entry you mentioned they discuss a workaround. I'm just not sure how to apply this workaround to a predefined Microsoft control (you'd think they would've implemented it themselves).

Maybe I just need to rethink the interface I'm working on a bit. A TreeView with over 65k nodes in it isn't going to be fun to use. :/

Still, I'd be interested to hear if anyone else who experienced this problem ever came up with a workaround.

Thanks for everyone's input so far!

[andywestken]

Are you actually adding 65k+ entries to the tree?

By then, a lot of people have switched to a virtual tree view.

[Jobizzu]

Yes. The way the app works is it reads in a data file supplied by one of our users, and lists certain pieces of information in the tree. Unfortunately, some of our users provide files that have hundreds of thousands of these piece of info, so the tree can become pretty full.

I might look into the virtual tree view you suggested, or possibly just re-think the GUI.

[webJose]

Unfortunate bug for sure, but I'll +1 your idea of re-thinking the GUI because let's face it: How useful will it be for a person to manually traverse thousands of entries in a treeview? Looking for something in particular? Then provide a Search feature. Aggregating data? Then provide some aggregation functionality. I really cannot think of anyone in the 21st century browsing 65K+ lines of data to achieve something by hand.