Keyvan Nayyeri

Regular visitors can remember that I had written some posts about writing a custom workflow activity to clarify things.  I got good feedbacks for those posts so decided to write a few posts about similar stuff in WPF about building a custom WPF control.  So this post and some future posts will cover the topic of different ways of customization in WPF and their different aspects.

Building a custom control in WPF isn't as common as building a custom control in other UI engines and technologies because there are several ways to customize a built-in control for your needs rather than building a custom control.  All built-in controls are customizable in different ways (using appearance attributes) and this is an advantage of WPF.  On the other hand it's possible to create user controls and apply them in applications to create a new controls based on existing controls.

But however there are some cases that you need to build a custom control.  One of most common cases is when you want to something new to code functionality for a control for your needs.  In this case you need to derive from your base control and add extra functionality to it.

Writing a custom control consists of some steps that I want to cover but here first I prefer to give a background about basics.

Building a custom WPF control is nothing more than writing a class and inheriting this class from a base class that is provided in WPF.

First step in development is to choose the most appropriate base class for your needs.  There are several base classes in WPF hierarchy that can be chosen for base class but you should choose the most appropriate one to have the best result.

For example in a hierarchy manner, FrameworkElement is derived from UIElement and UIElement is derived from System.Windows.Media.Visual and this hierarchy follows to upper level to reach to root.  On the other side System.Windows.Controls.Control is derived from FrameworkElement and ContentControl is derived from Control base class.  This ContentControl is a base class for some other controls that you use in WPF like HeaderedContentControl.  Below is a diagram of this hierarchy that I took from here (you don't see the upper levels).

Sometimes you need to deal with lower level APIs and have to choose something in leafs or lower levels but sometimes you need to work directly with some basic structures and have to choose an upper level base class.

After creating a Class Library project and adding some WPF references to it I create a new class, MyControl, to implement my custom control.  For example if I'm interested to write a custom content control then I can choose ContentControl base class for my control.

Or I can create an item based control and derive it from ItemsControl.

The important key is to choose the right base class.  Choosing a base class from upper levels when you can choose something in lower levels has its own problems.  For example you miss some built-in functionality that is ready for use in WPF and may need to write it yourself.  In opposite direction choosing a base class from lower levels when you have to choose one from upper levels has other problems because you won't be able to write your codes and accomplish to what you have in mind and later need to change your base class which may cause to change other codes as well.

Alright, it's enough for this post.  In next posts I'll talk about ways to add your properties, events and ... to your custom controls.