Basics: Templates for using controls very much

Windows®presentation Foundation (WPF) offers an exciting feature, a template, for programmers who prefer to turn a common control into a very visual object. The functionality of the control and its visual appearance are always controlled by complex control code. In WPF, the functionality of a control is still implemented through code, but the visual effect is separated from the code and exists in the form of a template defined in XAML. By creating a new template (typically in XAML without writing any code), programmers and designers can radically modify the visual appearance of a control without changing the control code.

In the opening column a year ago, I talked about how to design templates for ScrollBar, ProgressBar, and Slider controls. But the templating feature has pros and cons: When you design a new custom control, you provide a default template for the visual appearance of the control and allow the template to be replaced by the programmer who uses the control. You don't have to construct a control like this--in fact, there are no custom controls that define replaceable templates in flops "applications = code + Markup" (Application = codes + tags) (Microsoft press®, 2006)--but if you do , the person who needs to use the control (including you) will be much more convenient.

The purpose of this column is not to create a full-featured, good-looking control, but to establish a mechanism for defining a default replaceable template for a control that is distributed in a dynamic-link library. Many of the templating techniques I'm discussing here are learned by studying templates on existing WPF controls. If you want to do the same, the Dumpcontroltemplate program in chapter 25th of "Applications = code + Markup" (Application = codes + tags) enables you to extract the default templates from all standard WPF controls in a convenient XAML format.

Elements and controls

Programmers who have experienced the previous Windows client programming environment will soon find an interesting phenomenon in the WPF class hierarchy. For example, in the native Windows API, anything that has a visual look on the screen is categorized as a window, and in a Windows form, everything is a control. In WPF, however, the control class and many other visual objects (especially TextBlock, Image, decorator, and Panel) derive from FrameworkElement. So what's the difference between an element and a control?

First, the control class adds a very simple set of properties to the FrameworkElement class, including foreground, Background, and five font-related properties. Control does not use these properties directly, they are just for the convenience of classes derived from control.

Second, the control class adds the Istabstop property and the TabIndex property, which means that the controls are generally in the tab navigation chain and the elements are not. In summary, the elements are used for viewing while the controls are used for interaction (but the elements still get focus and respond to keyboard, mouse, and stylus input).

Third, the control class defines the Template property of the ControlTemplate type. This template is typically a visual tree of elements and other controls that make up the visual appearance of the control, and usually includes triggers that change this visual appearance based on property changes and events.

The third feature means that classes derived from control have a customizable visual appearance, while other classes derived from FrameworkElement do not. TextBlock and Image certainly have visual appearance, but customizing these visuals doesn't make any sense because they don't add anything to the formatted text or bitmap they display. On the other hand, ScrollBar can have a variety of skins, while functionality remains the same. This is the purpose of the template.

For programmers, the following may be the biggest difference between elements and controls: If you derive from FrameworkElement, to render the elements ' visual elements and their children on the screen, you will likely need to overwrite measureoverride, Arrangeoverride, and OnRender. If you derive from control, you typically do not need to override these methods because the visual effects of the controls are defined by the visual tree in the ControlTemplate object of the Template property.

WPF includes a class called UserControl, which derives from control by ContentControl. This UserControl is generally recommended as a base class for simple custom controls, and is widely used. For example, the DatePicker control in chapter 25th of flops derives from UserControl. But remember the significant difference between control and UserControl: When you derive from UserControl, you can define a visual tree in XAML, but this visual tree is a child of the Content property of UserControl. UserControl has its own simple default template, and you may not replace the template because it embeds contentpresenter inside the Border.

The visual tree of a class derived from UserControl is not intended to be replaced, so the code of the class and its visual tree can be more tightly coupled. Conversely, if you are going to derive from control and provide an alternative default template, the interaction between the code and the visual tree should be both simple and well-documented.