Custom vs User control

Question

I've been reading some explanations about the difference between User and Custom Controls, for example this: http://www.wpftutorial.net/CustomVsUserControl.html

I want to create, for example, a simple composition of a datagrid with 2 comboboxes which are responsible to change the values from the datagrid's items. I want to create a specific control for this because I'm going to use it a lot of times. I would like to implement the logic behind and then in the xaml invocation I only have to specify the itemsSource.

For this example should I create a User or Custom control? Since I will have properties and logic, should I have a viewmodel for this control?

EDIT: Do you know some articles with clear conceptual separation between these 2 options?

Solution 1

Choice is not only between user control and custom control, but among user control, custom control, customizing control template, customizing data template, header template (for collection based controls), attached properties. Refer to Control Authoring overview

I go by following order of consideration

1. Attached Properties : If functionality can be achieved, I use attached properties. Example, Numeric text box.

2. Control Template : When requirement can be fulfilled by customizing the control template, I use this. Example, circular progress bar.

3. Custom control: If control template cannot do it, I use custom control. Provided I need to customize/extend already present control. Example providing Sorting, Filtering based on header row in GridView (GridView is present in metro apps, used just to illustrate the example)

4. User control: Least preferred one. Only when composition is required, and I am unable to do it using custom control. Like in your example, 2 Combobox, and 1 datagrid. User controls does not provide seamless lookless feature that can be leveraged through custom control or control template.

Solution 2

You already have some great answers that explain the differences but also understand that custom controls and UserControls have different purposes:

A UserControl typically encapusulates some sort of composite behaviour. If you have an application that needs to edit contact details in many places, for example, you could create a custom control that has the labels and text fields for all the data laid out with a submit button that has the relevant code and reuse this control throughout your application.

A custom control is a control that is derived from one of the WPF control classes (E.G. Control, ContentControl etc.) and has to be created in code. These control usually have a single cohesive purpose (think TextBox, ComboBox, Label) rather than acting together as a whole (although this doesn't have to be the case).

UserControl's are usually easier for people unfamiliar with WPF as they can be visually designed.

My suggestion would be to start off with a UserControl. You can always refactor this into a custom control at a later date as you become more familiar with the way WPF works. Creating your control as a custom control will require knowledge of ControlTemplates and Styles as you will need to provide your own to define a look and feel for your control.

When all is said and done, as long as the control behaves correctly, it doesn't matter which approach you use.

See this post for an example of two approaches to the same problem. The post author wanted a control which can present modal content in front of the primary content. The post author actually answered his own question by implementing it as a UserControl. I have added an answer to the post which creates the control as a custom control but both have the same end effect.

Solution 3

• If you have a view-model and you wish to create a view for it use the User-Control.

• If you need an autonomous control that has no specific view-model,
  you probably need a custom-control.

• If you find that the functionality you need as whole, already exist in other controls you need to override an existing control template.
  (i.e: for a diamond shaped button - you need to override the button control template.)

• Regarding attached-properties and attached-behaviors, those are useful when you have a control which you want to extend with more properties or you want it to behave slightly different than its default behavior.

In the provided case of the composition the OP described, it can be achieved with either user control or custom control. I would prefer a custom control since there is no specific view model provided, the "input" is only a property bound to an item collection.

Oh, and, I am sorry for slightly being late.

Solution 4

The best explanation is in the msdn. CustomControl is more a "virtual" name, there is no class called "CustomControl" in WPF, instead its meant creating a new class building on top of one of WPF control classes, like Control, ItemsControl and even more specific Controls like TextBox or Button.

For your specific case, a UserControl should be enough, creating a CustomControl is something that can easily be avoided. While its not a bad thing, a lot of people, especially beginners in WPF coming from WinForms tend to subclass more then necessary.

Solution 5

You can easily Visually design CustomControl. Create new UserControl (or Window). Create its xaml structure visually in Designer. Copy-paste body of the resulting xaml inside ControlTemplate of your new CustomControl (Eg. in generic theme file).

If I remember right, you are also able to visually design CustomControl template directly, in Blend.

Of course you can also instance the wip CustomControl in a Window and put the Window's Designer view as new panel above the control's xaml view in VisualStudio. Some xaml bindings from style template don't show in Designer like this though, until I rebuild.

[ Imho GUI is mainly a visual matter and should not, and doesn't need to, be created in code. ]

View more solutions

Comments

[Louro]

thanks for the fast response. And how about the viewmodel option? I want to get the XAML as simple as possible, and I was thinking just to have one public property that would receive an ID that would be internally used to make some call to the business layer to get the data. For this situation it makes sense to me to have a viewmodel, but I dont know if I would lose reutilization power.

[dowhilefor]

@MBen sorry i maybe don't understand your first sentence but "To create a custom contrl your need to implement it as a user control", this is plain wrong a CustomControl has nothing to do with a UserControl, in fact you can write a huge application without any UserControls. Also "Your UserControl is called a custom control" thats also wrong, a UserControl is NOT a CustomControl in the original sense, subclassing a WPF Control, or your other CustomControls is called a CustomControl.

[dowhilefor]

+1 Wonderful, i would switch CustomControl and UserControl, but otherwise thats exactly how you should consider how to implement your custom ui logic. In fact i always see a CustomControl as the last possible option, and love doing tasks using Attached Behaviors.

[Tilak]

lookless behavior is what keeps me away from user control.

[Tilak]

i too love Attached behaviors. They makes the code cleaner, but at the same time, i dont like to overuse, where attached properties are sufficient, and donot require much plumbing

[MBen]

@dowhilefor I agree with you. However for me a Custom Control is a pre-built control that will be re-used by other developers. If I understood well this is the case for Louro . I agree with you , you can build a huge app without using UserControl. UserControl is used when especially you want to be a reusable piece of UI.

[MBen]

@Louro When building a custom user control your ViewModel needs to be a DependencyObject to declare Dependency properties. A dependency property is what you will use to bind to in the XAML. I would declare the ID as a dependencyProperty in the ViewModel.

[dowhilefor]

@MBen ben sorry again, but this is also wrong. A ViewModel doesn't need to be a DependencyObject (prerequisite for having Dependency Properties) it only needs to implement INotifyPropertyChanged.

[MBen]

@dowhilefor : Here you are totally wrong. For a proprty to be used in the XAML for binding it has to be a dependencyProperty. All WPF built in control have their proprties built as DP. We are talking about building a Custom User Control and allowing client to Bind, style, inherit from its property in the XAML. It has to be a DependencyProperty.

[dowhilefor]

@MBen You wrote "your ViewModel needs to be a DependencyObject" and i can guarantee you that this is 100% wrong. Of course you could do it but its not necessary. In WPF The Binding Engine can bind from Dependency Property to Dependency Property and, for general ViewModels, from Dependency Property to CLR Property. I aggree with you that for most of the properties on controls it makes alot of sense to make them Dependency property, but your sentence was clearly about viewmodel, where your statement is wrong. Check this link.

[MBen]

@dowhilefor : Yes we agree on that. But we are talking about build a custom user Control. Would you put the DependencyProperties on the Control? or would you put them in a ViewModel? You can't define normal properties in your control and expect the user to bind to them in the XAML. I repeat it, it has to be a dependencyProperty. Maybe may sentence was not clear. But lets put all those into the answer so that it helps Louro, and others after can find it useful :-)

[dowhilefor]

@MBen i certainly agree with that. :)

[Igor]

Also note that if want to later use your element as a container, you should avoid using UserControl, because you wouldn't be able to assign x:Names to its child elements. More info