"Programming WPF" translation 9th 4. Templates

Original: "Programming WPF" translation 9th Chapter 4. Templates

The final design consideration for a custom element is how it is connected to its visualization. If an element is derived directly from FrameworkElement, it will generate its own visualizations as appropriate. ( Chapter 7 Describes how to create a graphical appearance.) In particular, if you create an element to provide a specific visual representation, the element should have complete control over how the visualization is managed, and once you have written a control, you usually do not hardcode a graphic into it.

Remember that the work of a control is to provide behavior. Visualizations are provided by the control template. This visualization is provided by the control template. A control might provide a default set of visualizations, and should allow these visualizations to be replaced in order to provide resiliency like 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 the visualization is detached from the control and typically refers to a control that has no appearance. All controls that are inland to WPF have no appearance.

Of course, it is not possible 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 operating correctly. The extent of these requirements varies depending on the control. For example,a Button has a fairly simple need-just a placeholder to place the title or content. the Slider control requires a wider range of requirements: The visualization must provide two buttons (increase and decrease), "Thumb", and a trace on the run-time Thumb. In addition, it needs to be able to respond to clicks and drags on 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 some of the characteristics that represent the tree. The nature of this Convention relies on this control, and the inline controls use a few different styles, tightly dependent on their visual structure. The following sections describe a number of ways to associate a control with its template

9.4.1 Property Aliases

The most loosely contracted form between controls and templates is that the control simply defines the public property and allows the template to determine which property is visible in the alias. (See Chapter 5 For information on more property aliases.) This control does not care

What is in the control.

Here is a single-line convention: 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 visualization to the control. Controls can handle these events without needing to know any information about the nature of the visualization.

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 propertynamed Foo, the Brush type.

A dependency property that supports this control is mentioned by the user in the template, as shown in example 9-12 .

Example 9-12

<ControlTemplateTargetType="{x:type Local:mycustomcontrol}">
<Grid>
<RectangleFill="{TemplateBinding Foo}" />
</Grid>
</ControlTemplate>

Property aliases are automatically supported by all dependency properties. The "contract" in this case is implied by a set of dependency properties provided by your control.

9.4.2 Placeholder

Some controls want to find a specific placeholder element in the template. This will either take the form of the element that specifies the type, or it can be an element that marks a specific property.

control by deriving from the ContentControl supports content templates, using methods of element types. They want to find a ContentPresenter element in the template . This is an element of special intent, and its work is to assume a placeholder in other content.

In fact, this is a loosely enforced convention. If there is no contentpresenter in the template ,ContentControl usually does not appeal. Controls do not absolutely depend on the performance of the content, in order to put it to work. Or you can get to the other extreme, and put some ContentPresenter in your template, you can make child content appear multiple times.

you don't have to do anything special to support it . the use of ContentPresenter, as long as you derive from ContentControl, it can work very well. The user of the control can write a template, as shown in example 9-13 .

Example 9-13

<ControlTemplateTargetType="{x:type Local:mycontentcontrol}">
<Grid>
<RectangleFill= "White" />
<ContentPresenter/>
</Grid>
</ControlTemplate>

9.4.3 specifying placeholders through attributes

Some controls look for elements that are marked with a specific attribute. For example, controls that derive from ItemsControl, such as the ListBox and MenuItem, want the template to include a property with the Panel.isitemshost attribute set to the true element. This marks the host where the Panel will act as a control data item. The reason Itemcontrol uses subordinate attributes instead of placeholders is to allow you to decide what type of Panelto use as the host for the data item. (Itemcontrol also supports the use of Itemspresenter placeholder elements.) This will be used when the style does not want to take advantage of a particular panel type and wants to use whatever the default panel of the control is.

to implement a control that uses this technique, you need to define a custom dependent dependency property to apply it to the placeholder. This is a Boolean property. Example 9-14 registers such a subordinate property and defines the usual accessor functionality.

Example 9-14

Public classControlwithplaceholder:control{
Public StaticDependencyProperty Ismyplaceholderproperty;

StaticControlwithplaceholder (){

PropertyMetadata
Ismyplaceholdermetadata= NewPropertyMetadata (false,
NewPropertyinvalidatedcallback
(onismyplaceholderchanged));

Ismyplaceholderproperty=dependencyproperty.registerattached (
"Ismyplaceholder", typeof(BOOL),
typeof(Controlwithplaceholder), ismyplaceholdermetadata);
}

Public Static BOOLGetismyplaceholder (DependencyObject target){
return (bool) target. GetValue (Ismyplaceholderproperty);
}
Public Static voidSetismyplaceholder (DependencyObject target,BOOLvalue){
Target. SetValue (ismyplaceholderproperty, value);
}

Note that example 9-14 provides a propertyinvalidatedcallback for propertymetadata. This indicates a method that can be called at any time, and this secondary property can be set or modified on any element. In this approach, our control will discover which element is set as a placeholder, and example 9-15 shows this method.

Example 9-15

Private Static voidonismyplaceholderchanged (DependencyObject target){

FrameworkElement targetelement=Target asFrameworkElement;
if(Targetelement!= NULL &&Getismyplaceholder (targetelement)){
Controlwithplaceholder ContainingControl=
Targetelement.templatedparent asControlwithplaceholder;
if(ContainingControl!= NULL) {
Containingcontrol.placeholder = targetelement;
}
}
}
PrivateFrameworkElement placeholder;


}

This example begins with the detection property being applied to an object that is derived from FrameworkElement . Remember that we want this property to be applied to UI elements within a particular control template , so if it is applied to other elements rather than FrameworkElement, we do not get anything useful to do so.

second, we pass The Getismyplaceholder accessor method detects the property value, which we defined in the example 9-14 for the satellite property. This will be slightly separate if someone shows the setting this property is false, but if it does, we should simply not take the element as a placeholder.

If this property is set to true, we continue to get the TemplatedParent property of the target element . Because the element is part of the control's template, this returns the control to which the visualization belongs. (If this element is not a member of the control, then NULL is returned .) Since this property only makes sense for the elements in the template, we can't do anything without a templated parent level. We also examined the parent level as an instance of a control type, and ignored the property if it was applied to an element in a template, in some other type of control template.

example 9-16 shows how to use a property in a control template to indicate which element is in the placeholder.

Example 9-16

< CONTROLTEMPLATE&NBSP; targettype = " {x:type  local:controlwithplaceholder}
     < GRID&NBSP; local: Controlwithplaceholder.ismyplaceholder = "true" &NBSP; />
</ ControlTemplate >

Some controls want a template that provides a detailed set of elements that fulfill a particular role in the label of the control. For example, the Horizontalslider control wants the template to contain an element that represents a draggable thumb, a clickable trace, on either side of the thumb , and so on. The template needs to indicate which element is which. This can be accomplished by defining multiple subordinate properties using the techniques shown above.

when you write a control that uses a placeholder, you may choose not to execute the Convention. For example, if any part of the template is missing,the slider control does not complain. Once you have provided only a few elements to look for, this can work without complaining.

"Programming WPF" translation 9th 4. Templates