What is the difference between Custom Control and Custom Behavior?
Where Custom Control should be used and where Custom Behavior should be. in what ways they can be best used?
Behaviour extends control functionalities
Custom controls customize the visual of Control
A behaviour can be used to extend the functionality of a control to do something that it cannot do on its own without having to modify or re-implement the entire control.
Consider for example the built-in TreeView control in WPF. It has a SelectedItem property that is read-only which means that you cannot two-way bind it to a property of your view model. If you don't want to implement your own custom TreeView control from scratch just because of this - which you probably don't :) - you could solve this by implementing a custom behaviour that sets the value of your source property whenever the value of the target property changes and vice versa. Please refer to the following blog post for more information about this and an example: https://blog.magnusmontin.net/2014/01/30/wpf-using-behaviours-to-bind-to-readonly-properties-in-mvvm/
The following article should also provide a good introduction to attached behvaiours: https://www.codeproject.com/Articles/28959/Introduction-to-Attached-Behaviors-in-WPF
So a behaviour is basically a piece of code that can be attached to some element in the XAML markup of a view through attached properties and add additional functionality to this element.
A control is a UI component that encapsulates some functionality and has a template such, as for example a Button or a ListBox.
Behaviors encapsulate pieces of functionality into a reusable component.
Custom controls are more work than custom behaviors(White box vs black box)
Some things you have to do a custom control, eg Access Protected members.
Related
I have often bemoaned the fact that the WPF ToggleButton does not have properties for AlternateContent and AlternateContentForeground. I'm curious if there's any advantage to creating a DependencyObject with attached properties, or deriving a custom control from ToggleButton?
My assumption is that attached properties are advantageous if they are useable on more than one control. So in my case I'm leaning towards a derived control since those properties are unique to the togglebutton.
AttachedProperties are useful in a couple scenarios:
You want to use them as attached behaviors on things that interact with another Control, like Grid.Row
You want to add properties to a control but you don't want to force clients that get that behavior to be derived from your specific type. E.g. if you had a behavior that you wanted on Buttons rather than ToggleButton, then you may want to go with that approach so you could get that new property on ToggleButton and RadioButton, rather than forcing someone to derive from MyCoolButton.
For what you're describing just subclassing ToggleButton seems to make sense.
Actually, this kind of styling should be done with a trigger, or using the VisualStateManager.
I just want to wrap a standard control with some more additional properties (look stay the same, I don't want to do theming in first stage).
Can I just inherit from this standard control instead of UserControl or Control ? In fact I read it is obligatoryb to use Custom Control Project Template and not UserControl ontrol Project Template. Why ?
Update: I try with a Custom Control Project and inherit from the standard slider but I have nothing show up visually ! Now what should I do to have the same visual slider as the standard one ?
I know the difference between a user control and a custom control but in practice how do you do when you just want ONE single standard control ? How will a slider for example resize AUTOMATICALLY if I encapsulate it inside a User Control instead of a Custom Control ?
A custom control is a single control and can derive from another control, this would support styling. A UserControl is a composite control out of many different controls, and as a whole, doesn't support styling (the parts do however).
If you want to add features of any kind to an existing control, derive from it. If you want to pack several controls together to make it easier to handle them (you could still add DP's to it), use a UserControl.
A custom control alone won't do anything related to resizing etc, that is dependent on the settings you supply to it from the outside (ie. HorizontalAlignment, VerticalAlignment and others) when you used it in a container. The custom control should inherit the default template from the base class unless you override it.
I am creating a custom control derived from the one of the Standard WPF controls. The control has several constituent parts,and I am only modifying one of those parts.
Here's my question: If I am modifying only one part of a control, do I have to declare the control as lookless and reproduce the entire control template for the modified control in Generic.xaml, or can I omit the lookless declaration (found in the static constructor provided by Visual Studio) and simply modify the control template for the part I am extending?
I have tried the latter approach, and my control template is being ignored. I would like to get confirmation before I reproduce the entire control template, since what I am extending is the WPF Calendar. Thanks for your help.
It sounds like your best bet is to paste the entire template and modify the parts you need, although you didn't say exactly what you want to do or post any code.
Obviously if what you want to change about the calendar has a property you can modify in xaml, then that is easier. The opposite extreme would be to create a custom control (subclass).
I wanted to change the color or the ComboBox arrow the other day and the easiest way to do that was to past the entire template into a style and apply as needed, after changing one single part of the template (the arrow color, of course). There is no exposed DP to change for this and I didn't need anything more complicated than that.
HTH,
Berryl
The declaration that's generated for you by default is simply allowing for a default implicit Style to be defined for your control instead of just taking on the default Style of the base type.
DefaultStyleKeyProperty.OverrideMetadata(typeof(MyControl), new FrameworkPropertyMetadata(typeof(MyControl)));
What makes a control lookless isn't any specific declaration but rather it's definition in a code file which will then have some ControlTemplate applied to it at runtime. The alternative is the UserControl style of declaring a XAML+code-behind class which compiles into a single class with both UI and logic.
A simple example: Button is not the thing you see on the screen and click on; Button is a control that can take a single piece of Content and translate a user click into a Click event or Command call. What you see on the screen is just a visual template on top of Button's inherent behavior and state.
Can someone elaborate the difference between ControlTemplate and DataTemplate in wpf?
What should one use in case of custom controls? Like for example a StackPanel which possibly has an image and a TextBox?
It seems confusing in some cases where you define a custom control using the 'Content' property.
It would be great if an example of how each can be used in different scenarios can be provided.
A ControlTemplate is used to change the look of an existing control. So if you don't want your buttons to look rectangular, you can define a control Template which makes them look oval or any irregular shape. It's a way to customize 'look-less' stock WPF controls ; an alternative to writing your own user-controls. More details
A DataTemplate is used to specify how an instance of a specific class (usually a Data Transfer object - an object with properties) is to be rendered visually. e.g. define a DataTemplate to visualize a Customer instance in a listbox displaying all customers. More details
I have started writing some custom controls for a highly visual project. I was wondering what are your 'best practices' when coding WPF custom controls?
If you want your custom control to support direct content like this:
<CustomObject>
Direct content example 1
</CustomObject>
<!-- or -->
<CustomObject>
<Button Content="Direct content example 2" />
</CustomObject>
Then you need to use the ContentPropertyAttribute which tells WPF which property is actually being set when you write xaml like this.
The attribute can be used like this:
[ContentProperty("NameOfProperty")]
public class CustomObject
{
[...]
ContentControl uses this attribute to set the Content property but note that the property can be called anything; the WPF TextBox, for example uses this attribute to set the Text property.
E.G.
[ContentProperty("Text")]
The property also does not have to be a dependency property (see the MSDN documentation example for evidence of this).
Finally, this attribute is specific to the xaml parser and not to ContentControl and can be used with any type which can be seen from the TextBox example above (TextBox does not derive from ContentControl).
Keep property names the same as the property names for built-in Controls if you can do so without changing their meaning.
e.g. if you have a CustomerDisplayer custom control don't call the list of customers Customers, call it ItemsSource.
It might seem counter intuitive at first but it saves a lot of headache in the long run because future programmers can make a lot of assumptions about how a property called ItemsSource will act that they can't necessarily make about a Customers property.
Make sure the control can be re-styled and re-templated without changing the way the control operates. Don't make the control assume that the Listbox and Button are both within the same panel or that there even is a Listbox or Button. Check out the MSDN article on control authoring for some recommendations on how to do this.
Some content controls are dependant on the existence of other controls in their ControlTemplate. Typically this should be documented using the TemplatePart attribute.
The Combobox control, for example, is dependant on the existence of a TextBox and a Popup controls in its template.
This would be documented by placing the attribute on the class like so:
[TemplatePart(name="PART_EditableTextBox", type=typeof(TextBox))]
[TemplatePart(name="PART_Popup", type=typeof(Popup))]
public class Combobox : Selector
{
[...]
The naming convention is "PART_controlIdentifier".
The relevant items would then be given the same names in the control template so that they can be located in the OnApplyTemplate method.
This then allows the control to hook up to events, set properties and call methods on the controls contained in the template.
This attribute is for documentation purposes so that people designing custom control templates (and tools such as Expression Blend) know that the control is dependant on the existence of another.
Learn how to use both dependency properties and routed events (and how they work) so that you can use them effectively in your own control.
Both of these types provide services for integrating your control with the systems built into WPF.
By using these two features in your custom controls you will get the following advantages:
Dependency Properties provide support for databinding, animations and can be used in styles.
Routed Events can be propogated through the visual tree which means that other elements can handle the events.