treeview node index is Integer - how to circumvent that?

Component called Microsoft Windows Common Controls 6.0 contains a Treeview control, which has Nodes collection.

Every Node in this collection has .Index property which is of Integer value - max. value being 32767.

However it is possible to add to Treeview much more nodes than that and you can reference them with index numbers greater than 32767, for example:

tview.nodes(34234)

would return a correct node. I find that particulary strange, but since it works, I don't mind.

However:

tview.nodes(34324).Index would return negative value of -31211 (or something like that).

When that happens, it is quite easy to calculate "real" index number (that is 34234), but that way I can only calculate first 65535 nodes in the treeview. I thought that would be enough, but alas it is not so. Data I need to process consists of around 100.000 nodes (or more) and now I have a problem here, because the "real" index number is then quite impossible to calculate.

If I get node number 2000, it is really 2000th node or is it perhaps a node numbered 65535 + 2000?

Does anybody knows a way around this dillema? I suppose MS thought nobody would need a treeview with more than 32k nodes, but files I am getting are enormously big... :(

when dealing with a tree-view it's generally suggested that you use the key property instead of the index.
nodes are assigned indeces based on the order of creation, and they won't change when you sort the tree-view...

Ah.

But of course.

Well, it turns out that keys like "1", "2", etc. are invalid, for some unknown reason, but keys like "a-1", "a-2", "a-3", ... , "a-132032" etc. work with no problems.

I must say, VB6 has some strange behaviour indeed.

In any case, problem solved. Thanks for the idea. :)

You got my curiosity going -- always a good thing.
Anyhow, using CopyMemory API, one can return a positive Index from a negative integer index. Since you don't need that information, won't go into it here.

However, you also mentioned that your treeview may need to contain 100.000 nodes? Don't believe it will do that.

I ran a quick test and tried to add 70.000 nodes. When it was done, I ended up with 4.464 nodes which equates to (70.000 - 2^16 ). In other words, the treeview just started over when it hit 2^16, the previous 65.535 nodes were gone.
Sounds like you may need to reconsider how you display large treeviews. But I guess it is nice to know now vs later.