Introduction
This article targets Winform developers learning to create UserControls in Silverlight. Hopefully this article will help make the transition a bit easier. It assumes that the reader has a basic understanding of developing Silverlight applications and is now starting to write code.
Download Files
The download files have been created using Microsoft Visual Web Developer 2010 Express targeting Silverlight 4. If you don't have VS 2010 and are running a version of VS 2008 (with Silverlight 3 SDK) you should be able to copy the HierarchyNode or HierarchyTree files into your Silverlight project.
Background
I was looking for a free Silverlight hierarchy control but could only find third party controls, all of which cost money. So after creating the control, I thought I'd release it to the community and at the same time, write an article highlighting some of the issues experienced by Winform developers making the transition to Silverlight.
Using the Code
Once the control has been referenced or added to the project, the control behaves in a similar way to most controls. You can display any control within the HierarchyTree. The control must inherit from FrameworkElement (all Silverlight controls and UserControl inherits FrameworkElement). All controls should be of the same type and size.
Before displaying the tree, you will need to create the node structure using instances of the HierarchyNode class. The HierarchyNode has a Control property which handles a reference to the control you wish to display in the HierarchyTree. It also has a Children property which allows you to add child HierarchyNodes to the parent. By using this class, you will be able to create a hierarchical structure similar to the TreeView control we all know so well. The HierarchyTree has three properties worth noting:
LevelSpacing for defining the space between each level ChildSpacing for defining the space between child nodes and LineColor for setting the color of the lines joining the children to their parents
MyHierarchyTree.Items.Clear();
HierarchyNode JohnNode = CreateNode("John");
HierarchyNode JoeNode = CreateNode("Joe");
HierarchyNode ZaneNode = CreateNode("Zane");
HierarchyNode HugoNode = CreateNode("Hugo");
JohnNode.Children.Add(JoeNode);
JohnNode.Children.Add(ZaneNode);
JohnNode.Children.Add(HugoNode);
MyHierarchyTree.Nodes.Add(JohnNode);
MyHierarchyTree.Display();
Points of Interest
From a Winforms point of view, the nuts and bolts of creating a UserControl are much the same. However there are a number of design issues to address when building Silverlight controls.
Namespacing
Changing the namespace of a control isn't as trivial as you might first think. By changing the namespace in the code behind class will, among other things, cause the InitializeComponent method to throw an exception. This is due to a number of references within the project, not least the XAML code. Therefore use “find and replace” to change the namespace. Don't Replace all. Find next and replace only the appropriate namespaces. Not only will you avoid chasing your tail but it will give you a better understanding of how a Silverlight project is constructed.
Properties
Properties are also handled in a different way using the DependencyProperty.Register method.
public static DependencyProperty ChildSpacingProperty =
DependencyProperty.Register("ChildSpacing", typeof(double),
typeof(HierarchyTree), new PropertyMetadata(20d));
You will find a wealth of information on DependencyProperty already on the net. So there is no point going into detail here other than to say that although some complain about having to write the extra code, there are some advantages. DependencyProperty enables setting default values and raising change events.
EditorBrowsableAttribute
Properties in your Silverlight control are visible in the Properties Window by default. The BrowsableAttribute is no longer supported in the .NET 4.0 Framework. So although this is not Silverlight specific, it's worth noting that properties you wish to hide from the Properties Window need to be decorated with the EditorBrowsableAttribute.
[EditorBrowsable(EditorBrowsableState.Never)]
Drawing
The System.Windows.Shapes replaces the Systems.Drawing classes in Winforms. The reason for this is Silverlight is XAML based. The good news is the System.Windows.Shapes is intuitive and easy to use. In fact, if you're used to using GDI+, you'll find the System.Windows.Shapes classes a lot of fun. Many are displayed in the Toolbox so it's a simple case of dropping a few on the designer to get a feel of how to use these classes. Just beware that the designer doesn't always describe the shape correctly in XAML, so if it's not behaving as expected, check other examples on the net.
The Visual Studio Designer
The designer is back in Silverlight 4. Silverlight 3 didn't support the designer and that made moving from a Winforms environment to Silverlight hard because all design work had to be cut in XAML or by using Expression Blend. Now that it's back, it makes creating controls a lot easier and puts Winform developers back in the comfort zone. It's a bit flaky, a lot like the ASP form designer but it makes a huge difference to developing controls and generates the boilerplate code. So once you have fleshed out your control using the designer, you're probably better off leaving the designer as a display tool and finish tweaking the design in XAML.
Final Note
I hope this article has highlighted a few stumbling blocks not always mentioned in other tutorials and you enjoy using the HierarchyTree. The control has been developed to a basic level and has great possibilities to extend further. This control meets my requirements for the time being. I hope you also find it useful.
History
- 29th January, 2010: Initial version
- 19th October, 2010: Source code updated - includes added functionality to display the tree as either branches or roots
