When creating custom controls (not user controls) in WPF or Silverlight, the control creator typically supplies a default control template to give a default look to her control, but a client can change that control template using the Template property (inherited from Control). This is the standard way of working.
If some part of the template requires data binding, it’s not supplied with the default template: if it did, a client wanting to replace the template would have to correctly preserve the data binding expressions, which may be difficult or even impossible (if converters are involved, for instance). Instead, the control author creates the bindings in code, alleviating this burden off the client.
Here’s a simple custom control template example:
The control itself exposes a dependency property that should be data bound to the supplied slider (if any). The way to “find” that slider is to name it explicitly and advertise on the control class that this named part is significant, and should be supplied:
The TemplatePart attribute indicates which name is needed and what minimum type of element is acceptable.
Now, when the control’s template is applied (whether the default template or a custom one), the control looks up the element in its OnApplyTemplate override and hooks data binding, events, or whatever else may be necessary for the control’s intended behavior.
Suppose that in our control, the following dependency property is defined and we would like it to data bind to the found “slider” (something that derives from RangeBase), and that that binding should be a two way binding. Here’s the property’s definition (WPF):
Here’s the start of the OnApplyTemplate override:
Now we need to connect the dependency property to the Value property of the RangeBase object.
Here’s one way to make the connection, assuming the requested control exists:
Since it’s a two way binding (and no converter is needed), there is another way:
This apparently achieves the same thing: both are dependency properties, no converter is needed, so why should we care who is the source and who is the target?
Let’s place the control in some WPF window:
We’ve bound the TheValue property to a text box, so that moving the slider (from the default template) changes the text and vice versa. Surprisingly enough, this works with one of the previous data binding options, but not both. Can you guess which is the “good one”?
The answer is that the first option fails, while the second succeeds. Why? The binding seems the same – it’s two way, no converter, what’s going on?
Curiously enough, if we change the binding in the client, so that the textbox Text property is bound to the TheValue property – everything works in both binding ways!
The solution to this conundrum is that in WPF/Silverlight, a target dependency property may be bound by a single data binding expression. That means that in the following line:
The target is the TheValue property, meaning that it’s bound to something else (as target), and such it loses its original binding.
The moral of the story is: when you’re writing custom controls, bind your dependency properties as source and not as target whenever possible, to give your clients more freedom on how to data bind properties in your control.