Towards a more functional TreeView

Over the past few days questions have been rolling in on the Windows Forms .NET Forums over the functionlity of the TreeView control in Windows Forms.  There really isn't any relief for these questions since the basic control only thunks out to the Win32 version of the TreeView which is itself, not extremely functional.  Among the questions currently being posed are:

  1. Why can't the TreeNodes be shared amongst several TreeView controls?  I'm guessing some individuals are actually swapping the nodes back and forth for some type of filtered view scenario.  It can be a reall pita to have to clone the nodes all the time, and if nodes begin to run through the edit process, you don't even want to know about all the code that has to go in for synchronization.
  2. How do I do a meaningful merge of two sets of TreeNodes?  This would actually answer some of your synchronization questions, unless you wanted real-time synchronization.  Basically, merge the cloned tree nodes back into the main tree at some point.  The algorithm isn't expressly difficult, but it doesn't exist, and that confuses quite a few people.  Currently, if you try to just add the nodes back into the three, you'll end up with two versions of the nodes.  I did manage to come up with an answer to this one over on the Forums.
  3. The most pressing complaint I've heard is actually over on the Avalon newsgroups.  There is some big debate on how cool the Avalon TreeView will actually be and I'm enjoying sitting on the sidelines and watching the feature requests role in.  I'm thinking the coolest feature request I've seen so far is in regards to how the tree is rendered.  Seems people want a general purpose hierarchical container where each node can be any form of UI element that you might want to render.  Think about that for a minute, because the UI implications and different types of views start to become limitless with a relatively small amount of code.

Well, I have to say I love the TreeView control myself.  There are some issues everyone runs into when using a really nice control with huge numbers of features, but with a little patience most of them can be overcome.  Shared TreeNodes you want?  Then generate a factory object that maintains listings of peer nodes and manages the property changes so they propagate around.  Merging nodes you think you should have?  Check out my code samples posting and see if the algorithm might be useful to you.  General purpose hierarchical display you say?  Well wait for Longhorn and play with the developer preview release because you might be seeing a really cool tree implementation in the near future.

Published Sunday, January 18, 2004 3:27 PM by Justin Rogers
Filed under:

Comments

Monday, January 19, 2004 3:58 AM by Frans Bouma

# re: Towards a more functional TreeView

The real problem is under the hood. The .NET treeview is based on the asynchronous message model of win32. This means that when you do something synchronously in .NET, it is executed under the hood by sending win32 messages. This can result in serious issues.

.NET needs a synchronous, native gui library which is synchronous all the way till GDI+. The decision to base the gui glyphs on win32 stuff is perhaps based on teh fact that it would be 'faster' and 'easier to implement', but it also is the basis for most issues with .NET gui controls.
Monday, January 19, 2004 6:59 AM by anon

# re: Towards a more functional TreeView


Many great things about the windows forms treeview? It doesn't even support multiple selection natively. I think at least half of applications need that.


"Think about that for a minute, because the UI implications and different types of views start to become limitless with"

I don't know if this encourages consistent look and feel UIs, and how much this will hurt average people that are now used to the tree ctrl in windows explorer. In the corporate world, any change in the look and feel and UI costs millions in retraining. I would be willing to know how much corporate IS are spending to get people to upgrade to Windows XP, only for the required retraining. Interesting.



Monday, January 19, 2004 1:20 PM by Raymond Chen

# re: Towards a more functional TreeView

If a single treenode could shared among multiple treeviews, what would it return for the Parent property or IsExpanded or any other property that can be different in the two treeviews.
Monday, January 19, 2004 8:01 PM by Justin Rogers

# re: Towards a more functional TreeView

I realize there are some architectural issues with my original comments, some things that need or should have been thought through more thoroughly. However, the base points shouldn't be lost. For instance:

While a basic TreeNode has properties that make it functional only when located in a single tree, there are things that could have been done to make multiple view synchronization easier. The current TreeNode can't even have an overriden Text property to allow treenodes to notify a container or factory that it's value has changed and that synchronization needs to occur.

I labeled the article, Towards a more functional TreeView for a reason. I think work can be done to make it better, and I've shown in at least one case exactly what can be done. I'll show the same in another case relatively soon, because the concept of a TreeNode factory that allows you to make *connected* copies that automatically synchronize with one another actually works. And it isn't hard to do at all.

And yes, the Parent property and IsExpanded properties between the various views might actually be different, but the Text property and any properties you add that should be synchronized could easily be.
Wednesday, January 28, 2004 7:42 AM by Raymond Chen

# re: Towards a more functional TreeView

It's a question of pay-for-play. Do you want to complicate the base treeview with these features (that probably few people will actually use)? You can do a good chunk of this yourself - split your treenode into two objects, a treenode and a treenodedata. create multiple treenodes that share the same treenodedata.

Leave a Comment

(required) 
(required) 
(optional)
(required)