Control Authoring for dummies
Charles Petzold don't always use nice pictures to illustrate his WPF code (If you missed it look here) but he sure can explain! Lately I have been practicing create custom controls. When creating custom controls, you are sure to wonder: "from what should I derive?" The two top choices are Control vs FrameworkElement. What is the difference? Well, here is Mr Petzolds take on it:
"First, the Control class adds a collection of very handy properties to the FrameworkElement class, including Foreground, Background, and five font-related properties. Control doesn't use these properties directly—they're for the convenience of classes that derive from Control.
Second, the Control class adds IsTabStop and TabIndex properties, implying that controls often need to be stops in the tab-key navigation chain, while elements do not. In short, elements are for looking and controls are for interaction (but elements can still obtain focus and respond to keyboard, mouse, and stylus input).
Third, the Control class defines the Template property of type ControlTemplate. This template is mostly a visual tree of elements and other controls that make up the control's visual appearance and also often contains triggers that change this visual appearance based on property changes and events.
This third feature means that classes that derive from Control have a customizable visual appearance, while other classes that derive from FrameworkElement do not. Certainly TextBlock and Image have a visual appearance, but customizing these visuals doesn't make sense because these elements don't add anything to the formatted text or the bitmap they display. A ScrollBar, on the other hand, can have a variety of appearances and still be functionally the same. That's what the template is for.
For a programmer, here's perhaps the biggest difference between elements and controls: if you derive from FrameworkElement, you'll very likely need to override MeasureOverride, ArrangeOverride, and OnRender to render the element's visual elements and its children on the screen. If you derive from Control, you do not usually need to override these methods because the control's visuals are defined by the visual tree in the Template property's ControlTemplate object.
WPF includes a class named UserControl that derives from Control by way of ContentControl. This UserControl is often recommended as a base class for simple custom controls, and it serves fine for many purposes. The DatePicker control in Chapter 25 of my book derives from UserControl, for example. But keep in mind this important distinction between Control and UserControl: when deriving from UserControl, you can define a visual tree in XAML, but this visual tree is a child of UserControl's Content property. UserControl has its own simple default template that you probably won't replace because it simply nests a ContentPresenter inside a Border.
The visual tree of a class that derives from UserControl is not meant to be replaced, so the code of that class and the visual tree can be more tightly coupled. Conversely, when you intend to derive from Control and supply a replaceable default template, the interaction between the code and visual tree should instead be both simple and well-documented."
Full article available here
This is probably the most clear explanation I have found yet!
It is very important to realize that Control.Template is only available if you derive from Control!!! This is also the bases of most of WPF's lookless controls!!!
If you are new to control authoring, I would also recommend looking at Kevin Moore's bag-o-tricks! He has a excellent example of how to create a ColorPicker (Originally also available in Charles Petzold's book).
Also have a look at Marlon Grech's AvalonControlLibrary.
Disclaimer: WPF has done a excellent job of reducing the requirement for custom controls by allowing developers the freedom to change standard WPF controls visual tree and re-using them. If you really need to create your own components, find the lowest class to derive from that provides the functionality you need.
It is also very common to subclass a existing control and add functionality. Have a look at InfoTextBox (Also from Kevin's bag-o-tricks)
