MSDN Magazine - January 2008 - (Page 117)

Templates for Uncommon Controls CHARLES PETZOLD or programmers who enjoy turning common controls into uncommon visual objects, Windows® Presentation Foundation (WPF) offers an exciting feature known as the template. Traditionally, the functionality of a control and its visual appearance were bound together deep within the control’s code. In WPF, the functionality of a control is still implemented in code, but the visuals are decoupled from that code and take the form of a template defined in XAML. By creating a new template—most often in XAML without a lick of code—programmers and designers can completely revise the visual appearance of the control without having to modify the control’s code. In my inaugural column one year ago, I showed how to design templates for ScrollBar, ProgressBar, and Slider controls. But the templating feature has a flip side: when designing a new custom control, you should provide a default template for the control’s visual appearance and also allow that template to be replaced by programmers using your control. You aren’t strictly required to structure your control like this—indeed, none of the custom controls in my book Applications = Code + Markup (Microsoft Press®, 2006) define replaceable templates—but people who need to use that control (including you) will be a lot happier if you do. The purpose of this column is not to create fully functional and picturesque controls but to establish the mechanics for defining default replaceable templates for controls distributed in dynamic link libraries. Many of the templating techniques I discuss here I learned by examining templates on existing WPF controls. If you want to do the same, the DumpControlTemplate program in chapter 25 of Applications = Code + Markup lets you extract the default templates from all the standard WPF controls in convenient XAML form. F Elements and Controls Programmers with experience in previous Windows client programming environments soon discover a curiosity in the WPF class hierarchy. In the native Windows API, for example, everything that has an on-screen visual appearance is categorized as a “window,” while in Windows Forms, everything is a “control.” But in WPF, the Control class derives from FrameworkElement, as do many other visual objects—most notably TextBlock, Image, Decorator, and Panel. What exactly, then, is the difference between an element and a control? First, the Control class adds a collection of very handy prop- erties 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 In WPF, a control is still can still obtain focus and reimplemented in code, spond to keyboard, mouse, and stylus input). but the visuals take Third, the Control class the form of a template defines the Template properdefined in XAML. ty 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, january2008 117

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2008

MSDN Magazine - January 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Cutting Edge IIS 7.0 - Enhance Your Apps with the Integrated ASP.NET Pipeline World Ready - Around the World with ASP.NET AJAX Applications WCF Syndication - HTTP Programming with WCF and the .NET Framework 3.5 Wicked Code Foundations Extreme ASP.NET {End Bracket}

MSDN Magazine - January 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.