Reaction to: A Simple WPF Explorer Tree

Sacha Barber recently posted an article to CodeProject titled “A Simple WPF Explorer Tree.” The article shows how to lazy-load the TreeView control with the directory structure on your machine. It is a nice gentle intro to lazy-loading the WPF TreeView, and I highly recommend checking it out.

After reading Sacha’s great article I felt that something was amiss. In his demo, the root level items in the tree have a “drive” icon, and all other items have a “folder” icon. The way he implemented the logic which determines which icon to use involves a value converter. A TreeViewItem’s Image element, which displays an icon, has its Source property bound to the Header of the TreeViewItem. That binding has a converter which looks for a backslash character in the header text, and if it finds one that means the item is at the root level (i.e. it represents a drive, not a directory). For example, if the value converter receives “C:\” as the header text, it returns the “drive” icon.

The value converter contains the names of the icon resources, and it actually loads a BitmapSource using those hard-coded resource identifiers. This is what I have a problem with. I think that hard-coding resource identifiers in things like value converters and template selectors should be avoided because it severely limits the reusability of those classes.

There are at least two other ways to go about implementing this icon selection functionality that do not involve sticking resource keys into a value converter. The first option is to allow you to set the icon file names (the resource identifiers) as properties of the value converter. That way you can specify which icons to use in XAML, and the converter is only required to know how to analyze the data it is passed.

I don’t like that option too much. I really don’t think that using a value converter is ideal in this situation. The converter is basing its logic off of the presence of a certain character in the header text, which works just fine, but feels brittle to me. I think that the structure of the TreeView and its items should provide all the information we need, not the arbitrary contents of the data in the items.

The solution I came up with involves applying an attached property to the root level items, and then using DataTriggers to bind against that property and decide which icon to use. Here’s the code. First we have the class with the attached property, note the default value is false:

(Sorry about the weird indentation there, my images can only be so wide…)

When we create the initial set of TreeViewItems, representing the drives on the computer, we set the IsRootLevel attached property on each item to true:

Finally, we have the template which specifies how each TreeViewItem should render its header. Notice that since the header is shown by a ContentPresenter, we need to bind the DataTriggers against a relative source which finds the associated TreeViewItem:

Download the demo project here: ExplorerTree (demo project) Be sure to change the file extension from .DOC to .ZIP and then decompress the file.

Watch my presentation at the WPF Bootcamp 2008

A few months ago I flew out to Redmond so that I could speak at Microsoft’s WPF Bootcamp.  I gave a presentation about implementing the Model-View-Whatever pattern in WPF, which was received very well by the attendees.  After giving that presentation I solidified the material into my ‘Using MVC to Unit Test WPF Applications‘ article on CodeProject.  This seminal work is the foundation of the structural skinning architecture seen in Podder.

The entire WPF Bootcamp 2008 was videotaped and recently published online.  Karsten announced it a few days ago in this post.  All of the videos and associated downloads are hosted in a Silverlight application (of course), which you can view here.  NOTE: That page comes up empty for me in FireFox, so be sure to open in it Internet Explorer.

You can find my presentation under Day 3.  It is called “Hello, Real World!” and runs for about one hour.  I highly suggest you check out some of the other presentations, too.  There were many interesting things discussed during the bootcamp.

In case you want to download the entire video file,which is quite large, you can grab them individually from this page.  My video is around 330MB so it might take a while to download it, but if you’re just dying to fill up that new external hard drive…  🙂

Pros and cons of Visual Studio Orcas support for WPF

I installed the Visual Studio 2008 (‘Orcas’) Beta 1 recently.  The main reasons I decided to install Orcas were so that I can start learning about Acropolis and LINQ. 

I have been putting VS2008’s support for WPF to the test; to see what improvements have been made since the Orcas extensions for VS2005 were released back in August of 2006.  In case you have considered moving to VS2008 for your WPF development but aren’t sure if it is worth the 6 gig download and possible destabilization of your machine, perhaps this information will help you make a more informed decision.

O Intellisense, Intellisense, wherefore art thou Intellisense?

Before getting into the pros and cons of Orcas, let me first make an important statement for all you VS2005 + Orcas extension users out there.  The standard XML Editor in Visual Studio no longer has XAML Intellisense!  When I first opened up Orcas, whipped up a new WPF project, and opened Window1.xaml I quickly discovered that there was no Intellisense! 

The XAML editor in Orcas is not the standard good old XML editor.  It seems to be a new editor, and only this new XAML editor has Intellisense support.  The old hackery in the VS2005 Orcas extensions, which used XSDs to provide XAML Intellisense, is no longer being used.  The standard XML editor is now unaware of XAML.

If your default editor for XAML files is the XML Editor, you’ll need to change it.  In Solution Explorer right-click on a XAML file, select “Open With”, and then choose the “Visual Studio Windows Presentation Foundation Designer” option, click the “Set as Default” button, and then click OK.

Pros and Cons

PROS

• The visual designer for WPF is more stable and has more features.
• It has cleaner and more organized XAML Intellisense, particularly when you use property element syntax.
• It has better XAML Intellisense support for attached properties (they appear as namespaces in the Intellisense window).
• There is a useful feature for mapping CLR namespaces into XAML, shows a list of CLR namespaces and which assemblies those namespaces are in.  You just select the namespace/assembly you want to map and it writes out the rest for you.  This even includes your “local” namespace too!
• Once a non-WPF namespace has been mapped into your XAML, the Intellisense will list types in that namespace, such as String, Int32, etc.
• Non-WPF types, such as your own classes, now have Intellisense support.  For example, it will display the public properties on classes which you created.
• The context menus in Solution Explorer make it quick and easy to add a WPF Window, Page, UserControl, and ResourceDictionary.
• After adding a named element in XAML, you do not have to compile the project for that element to be available as a field in the code-behind.  You only have to save the XAML file.
• The Property Window and XAML editor cooperate nicely.  The Property Window displays the element selected in the editor, and changes made in either view appear in the other.

CONS

• Orcas crashes and throws odd errors much more often than VS2005, which is expected of a beta release, but still is annoying when you are trying to get work done.
• Auto-completion of an XML element close tag is missing.  In the VS2005 + Orcas extensions editor, after you typed the closing angle bracket of an element it would automatically write out the element’s close tag for you.  That feature is sorely missed.
• Support for auto-formatting of XAML is gone (i.e. Ctrl + E + D no longer works).  That REALLY sucks.
• The WPF visual designer does not remember its state between runs.  It always opens the visual designer on top, at the same size.  Since I almost never want to use the visual designer, it’s annoying that I have to hide it every time I open a XAML file.
• The XAML editor does not auto-indent when you add a child element.  You have to hit Tab (or the Spacebar several times) to indent the child element appropriately.  This is just another time consuming task which I took for granted before.
• XAML Intellisense does not give an informative comment about a property or event; it only shows the type and member name.
• There is an inconsistent editing experience regarding auto-completed double quotes (“”).  If the property being set has a well-known set of values, like Background, then when you select a value it adds the quotes.  But for a property which requires you to type in the value, like Height, the quotes are not added.  This breaks my XAML editing flow and I find myself having to go back and add in double quotes around attribute values more often than I’d like to admit.
• Giving an element a name in the Properties Window uses the Name property, instead of x:Name.  I prefer x:Name for the sake of consistency since you cannot always use Name, but can always use x:Name.  This should be configurable.
• If you create a new class in your project and want to use it in XAML, you must close the XAML editor/designer and reopen it for the type to appear in Intellisense.

Wish List

• The Visual Designer should NOT always open by default when I view a .xaml file!!!  It should remember my previous settings.
• I’d love to have Intellisense support in markup extensions, such as showing the properties of a Binding, and displaying available resource keys when using StaticResource or DynamicResource.
• I would also like it if there was Intellisense support for things like Setter.Property, Setter.Value, Trigger.Property, Trigger.Value, etc.  That would make the whole styling system in WPF much more user-friendly.

Conclusion

The support for WPF in Visual Studio 2008 is headed in the right direction, but still has a ways to go before hitting the point where I would say that it is far superior to what the Orcas extensions for VS2005 provided.  In some ways I think that the XAML editing experience has been degraded, but that might just be due to the fact that I’m so accustomed to the “old way” of doing things.  Regardless, since Acropolis and LINQ can only be used in VS2008, I will be using VS2008 from now on.