Fog Creek Software
Discussion Board




Store Hierarchy in Treeview tag property

I have a hierarchy similar in nature to files and folders (I guess any hierarchy is <g>)

I used to maintain the hierarchy separately using linked lists and collections but the associated performance hit was prohibitive.

Consequently, I now store the object itself (group or item) in the tag property of the tree that displays it.  This allows me to pretty much ignore the editing issues associated with changing the tree with the exception of move up/down and changing levels through cut, copy and paste.

The speed is excellent and I've had no apparent problems but I'm wondering if I've overlooked anything?

Thanks

VB Monkey
Saturday, August 02, 2003

In C#, tree nodes are objects.  Are you inventing your own .net?  hehe.

Oh, that's right, in VB tree nodes are a collection, hah?  ah, yes, easier to understand collections, but I guess performance is the tradeoff.

Haven't compared speeds myself, just saying.

Brian R.
Saturday, August 02, 2003

I think what VB Monkey is saying is that he has a virtual hierarchy (object model if you will) that was previously only *represented* by the tree, but who's hierarchy is now *managed* by the tree.

Personally I think it's a good idea if you're not planning on re-using the object model in a non-gui situation.  What could be simpler?

I usually deal with hierarchies by using custom objects because I try to leave all of my apps open to the possibility of scripting them with the MS Script Control or Web Browser.  If I were to expose a Treeview to a scripting environment then add-in developers would have too much control.  But there is a small performance hit I suppose.

It all depends on the situation.

Wayne
Sunday, August 03, 2003

It's a not uncommon technique.

If you're doing it in VB6 or earlier and associating the treenodes using ObjPtr() values, then you should AddRef() the objects first unless you're maintaining parallel references somewhere else... also there should be parallel Release() calls before you remove any nodes.

You'll want to be careful about this in order to avoid invalid object references on the one hand, or memory leaks on the other.

If large heirarchies are accessed via a tree control, it's really better to build the tree on the fly using node event notifications in order to have decent performance - ie. if the thing is going to be huge and you build it all up front obviously you're going to have a load delay.

John Aitken
Sunday, August 03, 2003

Do you have any references John?  I've looked and only found an 8 year, relatively poor article.

There is a load delay but the responsiveness is excellent so the couple seconds has not been an issue.

Thansk again!

VB Monkey
Sunday, August 03, 2003

*  Recent Topics

*  Fog Creek Home