Assume we created a custom BaseControl with a DerivedControl.

  public class BaseControl : Control
  {
    static BaseControl()
    {
      DefaultStyleKeyProperty.OverrideMetadata(
        typeof(BaseControl),
        new FrameworkPropertyMetadata(typeof(BaseControl)));
    }
  }
  public class DerivedControl : BaseControl
  {
    static DerivedControl()
    {
      DefaultStyleKeyProperty.OverrideMetadata(
        typeof(DerivedControl),
        new FrameworkPropertyMetadata(typeof(DerivedControl)));
    }
  }

And we set the generic styles like so:

  <Style TargetType="{x:Type local:BaseControl}">
    <Setter Property="Template">
      <Setter.Value>
        <ControlTemplate TargetType="{x:Type local:BaseControl}">
          <Border Background="{TemplateBinding Background}">
            <TextBlock>Hello World!</TextBlock>
          </Border>
        </ControlTemplate>
      </Setter.Value>
    </Setter>
  </Style>
  <Style TargetType="{x:Type local:DerivedControl}">
    <Setter Property="Background" Value="Violet"/>
  </Style>

We created a BaseControl-style with a template with some text in it, and a DerivedControl-style giving it’s background some color.
If we run a simple test with a form containing a DerivedControl, we want to have a text with a violet background. But what do we get?

Exactly: an empty window. Not at all what we expected.

The problem lies in an incorrect assumption we make, because we are so used to the concept of inheritance and polymorphism. We created two styles with two different keys ({x:Type local:BaseControl} and {x:Type local:DerivedControl}). In the code of BaseControl we specify with the OverrideMetadata-method that we want the system to look for a style with a key equal to ‘typeof(BaseControl)’. In the code of DerivedControl we again override that metadata to make the system look for a style with a key equal to ‘typeof(DerivedControl)’. Since we override the metadata, the base-value is lost.

When the system want to construct a DerivedControl it reads the DefaultStyleKeyProperty from the control and gets a ‘typeof(DerivedControl)’. This is just a key, we could just as easily have given it a string reading “DerivedControl” to look for. The resource-resolver starts to try and find resources with the key ‘typeof(DerivedControl)’. It is to be expected that an resource with the key ‘typeof(BaseControl)’ will not be found, since the resolver only checks for equality. To prove that, you can check with Reflector and look at the internal method System.Windows.FrameworkContentElement.FindResourceOnSelf() where you can see it checks wether a resource exists using ‘dictionary.Contains(resourceKey)’.

In the debugger screen to the right you can see the derivedControl instance does get its background set, but not the template. The control does get it’s own style applied, setting its BackGround to Violet, but there is no ControlTemplate to show us the color, because that’s in the style for the BaseControl!

Resolving this is easier than it seems, but it needs manual work. In the style for the DerivedControl we can add a BasedOn property. The xaml will have to read like this:

  <Style TargetType="{x:Type local:DerivedControl}" BasedOn="{StaticResource {x:Type local:BaseControl}}">
    <Setter Property="Background" Value="Violet"/>
  </Style>

Using that property we can tell the style it should first apply the BasedOn-style and afterwards apply it’s own setters. (We need the ‘StaticResource’ part because the BasedOn-property takes a Style, not a key.) Now our window looks like this:

Admitted, it is one ugly window, but at least it shows the way we told it to.

I personally think it is good practice to always set the BasedOn property for your styles to the style of the baseclass, and giving all baseclasses at least empty styles (without the empty style the StaticResource will fail to build).

Too bad the WPF-team didn’t really follow the BasedOn-principle; then we could have customized for example the style for System.Windows.Controls.Control, potentially triggering on all kinds of properties and see that style reflected in all derived controls. But alas, we have to use tricks involving attached properties to get things like that to work. I hope to post on that a little later on.

So here it is: my latest (and first) blog “Joep on Technology”.

I’m interested in lost of technogical topics, but mainly my experience lies at the development of applications for Microsoft platforms. That’s why I’ve decided to write my blog in English, instead of my native language Dutch. I’m hoping that my English blogs will be read by more people, considering that most developers are used to reading English documentation, regardless of their native language. I started a blog in Dutch half a year ago, but I noticed the fact i had to blog in Dutch was really a threshold for me.

So, Joep, what can we expect from your blog?

Well, frankly, I’m not sure yet either. I’m planning on just blogging on all kinds of topics I can come up with. I anticipate a few articles on hardware, electronics and stuff like that, but mainly i will be targetting .net development, c#, wpf, Windows Vista and related topics. But I guess only time will tell what this blog is going to be about. Could be anything that pops to my mind.

Hope to see you soon on my first topic with real content!