The WPF TreeView is a View of a Tree

I have been thinking a lot about the WPF TreeView control lately.  My recent article about it, which, by the way, is my wedding gift to Sacha Barber, discusses how the ideal way of working with a TreeView is to bind it to a ViewModel, and then program against the ViewModel.  This got me thinking.

When I first started learning about Windows Forms, I thought the TreeView control had a strange name.  Why not call it the Tree control?  Why did they add the word “View” to the end?  At the time, the .NET 1.0 era, I don’t think any other control had the word “View” tacked onto the end of its name, except for ListView.  After a while, I got used to the name and never gave it much thought, until now.

The WinForms TreeView control is not really providing a “view” of a tree: it is the tree.  You create a tree data structure in the control, where each node in the tree is of type TreeNode, and the control renders those nodes.  One could argue that the WinForms TreeView control’s name is a misnomer, because it can only show its own TreeNodes.  By the same reasoning, we should call the Menu a MenuView and the ComboBox a ComboBoxView, but that is not the case.  WinForms should have a Tree control instead of a TreeView control.

The WPF TreeView control is very different.  Granted, at the end of the day, it still has a tree data structure consisting of TreeViewItem objects, but the similarities end there.  We can use the TreeView in our WPF programs to literally provide a view of a tree.  The fact that the WPF TreeView supports data binding allows us to create a tree data structure, perhaps of custom ViewModel objects, and provide it to the TreeView control’s ItemsSource property.  At that point, the TreeView will do all the grunt work of creating TreeViewItems and hooking them together for us.  We are not required to focus much on the TreeView, but more on the data we actually care about.

We can provide in-depth customizations for how the TreeView renders the items, by setting properties such as ItemContainerStyle to affect properties of every TreeViewItem, and ItemTemplate to specify what each item should look like and where its child items come from.  We declare all of this in XAML, and let TreeView handle all the details of applying our styles and templates. We can remain focused on the tree data structure, it’s behavior, it’s state, and just tell the TreeView how we want to view the tree.

It might seem like a minor difference, but, in my opinion, it represents a significant change of mindset.  In WPF, the TreeView control provides a view of a tree.

3 Responses to The WPF TreeView is a View of a Tree

  1. Kevin Kerr says:

    I’m not trying to sound like the broken record ‘nice post’ comments… but you could not have put it any better. WinForms forces developers to hack around in the UI with logic/data etc. WPF provides the capability to design things they were meant to be designed.

    The WinForms has the short term benefit of ‘oh I have the UI right here I can make my treenode do this…” yet the long term downside of UI code mixed with other logic. WPF has the short term pain of “how do I design this to support all of the needed UI/user features, yet still interact with my data/logic”

    WPF makes it easy to create modular, flexible, and simple designs. The problem is that it is not easy to create modular, flexible, simple designs.

    These ‘narrow’ M-V-VM articles that you, me and others do are fantastic and useful (yours the most), but unfortunately a high percentage of developers probably do not know how to take it to the next level of designing an entire application using M-V-VM (or other variants). I do not mean anything negative by that statement other than it is simply ‘hard’ to do. Hopefully you and others keep up such great community work. Perhaps someone one day will write a ‘holy-grail’ guide demonstrating a large application using the M-V-VM pattern. Your MVC article is currently probably the closest thing to it.

  2. Josh Smith says:


    I agree that an article about a large MVVM app would be very useful. I think that my Podder application is a good “large” example of using MVpoo, but I never wrote an article specifically about how the whole app works.


  3. Kevin Kerr says:

    Ah yes, Podder!

    Podder is more than MVPoo… it is M-V-Poo-Skin. Yet another knockout WPF contribution.

%d bloggers like this: