My personal WPF WTF list has grown steadily since I started to work with WPF. In my opinion, WPF is filled with bad naming conventions, inconsistencies and just…bad smell.

As my work with WPF progress, I will write some blog posts where I will vent the steam that builds up when I am faced with such WPF goodies.

Before I go on, I want to underline that I find the WPF technology in itself impressive. However, it seems that MS squeezed too much into the WPF universe at once. If they aimed at replacing Windows Forms, they should have put more effort into making the new standard consistent…and also applied to conventions that already exist out there.


For instance, let’s take the Border control, which can have…a background. To me, that’s not just bad design. To me, that serves as a prime example of the rotten smell that leaks out of WPF. It breaks SO many conventions.

First of all, let’s talk about the border concept. What do we mean?

Well, if I would say “let’s put a border around that thing over there”, “the thing over there” would be something that is responsible for its entire context. The border would just something that will get smacked around it. It may be thin, thick, green, aquatic, slimey…I do not care. It will surround “the thing over there”. That’s it.

Second of all, if you have worked with web development, you may know the border concept as something that can be applied to divs, spans, images etc…that is, most kinds of graphical components. In these cases, “the thing over there” is a graphical component, and my definition above still applies. This border concept is also applied to great extent in the Windows Forms framework.

So, why change the border concept in WPF? Why not call it something else?

In  my opinion, all the examples below would be better than Border:

  • Panel (did they not want to re-use this name?)
  • Container
  • Box
  • Div (yeah, even Div would be better than Border)
  • SurrounderThingie
  • Kwanzabalubah

By naming this UI component Border, MS changes the meaning of an already established concept. DO NOT CHANGE THE MEANING OF AN ALREADY ESTABLISHED CONCEPT!


Now, as I wrote earlier, the Border example is just ONE example of the rotten smell that leaks from the WPF framework…but a damn good one. Let’s move on to the CheckBox control.

If a Border is something that surrounds something else, a check box is something that we have come to known as a UI control that can be either checked or unchecked. It maps beautifully to a boolean value.

Well, except in WPF. In WPF, the IsChecked property is nullable (bool?), since it can also have an undetermined state. Wow, that changes everything.

To me, if a checkbox is not checked, it is not checked, unchecked, whatever. Simple as that. If MS wanted to change this, perhaps they should have introduced a new UI control (it could even inherit a regular CheckBox). It could have been called:

  • NullableCheckBox
  • FuzzyCheckBox
  • CheckBoxGoodForSwedishDecisionMakersWhoDoNotWantToMakeADecision
  • NotReallyACheckBox

By mapping this new kind of behavior to the check box concept, MS changes the meaning of an already established concept. DO NOT CHANGE THE MEANING OF AN ALREADY ESTABLISHED CONCEPT!

WPF CheckBox enemy bonus content

After publishing this post, I decided that you deserve something in return, if you decide to join me in my war against WPF. How about a nice extension method to the CheckBox class?

   public static bool IsChecked(this CheckBox checkBox)
      return checkBox.IsChecked.HasValue && checkBox.IsChecked.Value;

Enjoy 🙂


Wow, that felt good.

Please, provide me with more examples. Maybe, in a not so distant future, we can have a clean WPF framework that conform to the rest of the world. Wouldn’t that be something?