Category Archives: .Net

WPF internals part 1 : what are the core WPF classes ?

In this first article, I’d like to make a tour of the core WPF classes and how they are related.

Knowing the organization of WPF classes is important when we create a new control because we have to determine which base class we’re going to use. It is also interesting to know how the framework has been designed. That’s the goal of this first article.

Here is an image of the core WPF classes and how they are related (click for larger resolution):

The diagram is voluntary simple above the Control classes because that will be targeted by another article.

The top level class DispatcherObject:

  • represents an object that is associated with a Dispatcher
  • can be accessed from a thread other than the thread the DispatcherObject was created on, using Invoke or BeginInvoke calls
  • can enforce thread safety by calling VerifyAccess
  • cannot be independently instantiated; that is, all constructors are protected

From the DispatcherObject class, we have 4 new classes (one more time, this is a partial view of what really is in the framework):

The DependencyObject class:

  • contains the mechanism to deal with Dependency Properties through a set of methods such as ClearValue, SetValue and GetValue
  • is inherited by 3 new classes
    • TriggerBase, for specifying a conditional value within a Style object. Inherited by DataTrigger, EventTrigger
    • Freezable, for object that has a modifiable state and a read-only (frozen) state. Classes that derive from Freezable provide detailed change notification, can be made immutable, and can clone themselves
    • and the Visual class,

The Visual class:

  • provides rendering support in WPF, which includes hit testing, coordinate transformation, and bounding box calculations
  • is the first class supporting the VisualParent property that helps setting up the visual tree
  • support methods for adding, removing and getting visual child (through the IAddChild interface)
  • has an VisualEffect property of type Effect (from Animatable / Freezable)
  • is inherited by the UIElement class,

The UIElement class:

  • can render as a child element
  • contains logic that is used to size and position possible child elements of a UIElement (when interpreted by a layout system)
  • can respond to user input (including control of where input is getting sent to via their handling of event routing, or routing of commands)
  • can raise routed events that travel a route through the logical element tree
  • supports some aspects of the animation system
  • is enhanced by the FrameworkElement class,

The FrameworkElement class extends the UIElement class by adding the following functionalities:

  • layout system definition using the ArrangeOverride method
  • logical tree with the Parent property
  • object lifetime events such as Initialized, Loaded, Unloaded
  • support for databinding (DataContext property) and resources management (Resources property)
  • support styles (Style property)
  • does not handle the Template feature implemented in the Control class

Several classes inherit the FrameworkElement class:

The Control class:

  • is the base class for WPF controls that use a ControlTemplate to define their appearance (through the Template property)
  • defines a set of UI properties (that can be exploited by ControlTemplates): Background, BorderBrush, BorderThickness, FontFamily, FontSize, FontStrech, FontStyle, FontWeight, Foreground and Padding
  • support mouse double clicks event using MouseDoubleClick and PreviewMouseDoubleClick

In order to show where most of the WPF controls are (but that will be the object of another article), I also added ContentControl, ItemsControl, UserControl and Window class to the diagram.

Analyzing events usage using a R# plugin

As you might already know, even if the .Net framework has a garbage collector, you can easily create memory leaks in your application.

The most common way to create a leak is to register to an event handler on a object that has a longer lifetime than the object where the handler is defined. The problem can also occurs by using static class such as EventManager (for more information see this blog post). Some .Net developers have been working on a way to go round the problem using Reflection, Weak Reference and other cool stuff. You can check out for example this excellent article on Code Project.

However, if you cannot change the way your declare events (because of internal policies in the company or because you don’t have the source code), you must be very carefull about the way you manage your events.

I’ve been working lately on a Resharper plugin that helps detecting events that are never unsubscribed. Basically, what is does is the following:

resharper_plugin

I’d like to have feedback from you .Net developpers, about whether you find such a plugin useful or not.

  • How do you deal with the event memory leak problem ?
  • Would you like to use my plugin ?
  • Would you like me to release it on a open source platform ?
  • What other kind of possible leaks are you thinking about to enhance the plugin ?

Please write a comment to let my know what you think. Thank you for your feedback !

Announcing the “WPF internals” series

I’m starting a new series of article I’m calling “WPF internals” where I’ll be reviewing how things works <inside> WPF. I haven’t the entire content yet, but here is a summary of what I’m planning to do:

  • Part 1 of N: what are the core WPF classes ?
  • Part 2 of N: how the WPF controls are organised ?
  • Part 3 of N: how ZIndex works ?
  • Part 4 of N: how InputGestures works ?
  • Part 5 of N: how databinding with DataContext works ?
  • Part 6 of N: how databinding with an ItemsControl works ?
  • Part 7 of N: what is the difference between a ContentControl and a ContentPresenter ?

I setup a new page in the header so that links are easy to access.

All the information that I’m going to give here is based on my PERSONAL understanding using tools like Reflector and VS Class Diagram Designer that help me figure out how things fit together. I’m neither a Microsoft WPF Architect nor a Program Manager on the .Net framework !

Please let me know if you’re interested in special topics, I’ll do my best to try to include them in the series. Please also feel free to leave comments on the articles so that if I’m misunderstanding something I can fix it.

I hope to post the first article this week (before October, 16th)