"Programming WPF" translation 9th Chapter 4. Template

The final design consideration for a custom element is how it connects to its visualization. If an element derives directly from FrameworkElement, this will properly generate its own visualization. (The 7th chapter describes how to create a graphical appearance.) In particular, if you create an element to provide a specific visual representation, the element should fully control how the visualization is managed, and once you write a control, you usually don't hard-code a graphic into it.

Remember that the job of a control is to provide behavior. Visualization is provided by the control template. This visualization is provided by the control template. A control may provide a set of default visualizations, but should allow these visualizations to be replaced in order to provide the same elasticity as an inland control. (The fifth chapter describes how to use a template to replace a control's visualization) a control that conforms to this method, where visualization is detached from the control, often referencing a control that has no appearance. All controls that are moving inland to WPF have no appearance.

Of course, it is impossible for a control to be completely independent of its visualization. Any control will affect the requirements that the template must meet if the control is correctly manipulated. The extent of these requirements varies depending on the control. For example, a button has a fairly simple requirement--just a placeholder to place a title or content. The slider control requires a broader range of requirements: Visualization must provide two buttons (add and decrease), "Thumb", and a trace on the runtime Thumb. In addition, it also needs to be able to respond by clicking and dragging any one of these elements, as well as being able to locate this thumb.

There is an implicit convention between any control type and style or template. This control allows its appearance to be customized by replacing the visual tree, but the tree must rotate to provide certain characteristics that represent the tree. The nature of this Convention relies on this control, which uses a number of different styles and relies heavily on their visual structure. The following sections describe a number of ways to link controls to their templates

9.4.1 Property Alias

The most loosely agreed form between a control and a template is that the control simply defines the public property and allows the template to determine which property is visible in the alias. (See chapter 5th for more information on property aliases.) This control does not care about

What is in the control.

Here is a single line of conventions: Controls provide properties and commands and do not need to return a value. However, if necessary, such a control can still respond to user input. Event routing allows events to bubble up from the visual to the control. Controls can handle these events without having to know any information about the visual nature.

To support this model, all you have to do is implement these properties using the dependency property mechanism described earlier in this chapter. Example 9-11 shows a custom control and defines a separate dependency property named Foo, brush type.

Dependent properties The user who supports this control is mentioned in the template, as shown in example 9-12.

Example 9-12

<ControlTemplate TargetType="{x:Type local:MyCustomControl}">
　　　 <Grid>
　　　　　　　 <Rectangle Fill="{TemplateBinding Foo}" />
　　　 </Grid>
</ControlTemplate>

Property aliases are automatically supported for all dependent properties. The "convention" in this case is implied by a set of dependent attributes provided by your control.