WPF WTF

Published 24 Mar 2011

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 and inconsistencies.

Before I proceed, I want to underline that I find the technology in itself quite impressive. However, it seems that Microsoft squeezed too much into the universe at once. If they wanted to replace Windows Forms, they should have put some more effort into making WPF consistent and applied to existing conventions.

Border

For instance, let’s take the Border control, which can have…a background. That is not just bad design. To me, it is a code smell - an indication that something is not right. It breaks SO many conventions.

First of all, let’s talk about the border concept. To me, a border is something that can be applied to a graphical component and can have a line width and color. It may be thin, thick, green, aquatic…I don’t care. That is what we most often see when we talk borders in web, open gl…and Windows Forms.

So, why change this 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, Microsoft changes the meaning of an already established concept. DO NOT CHANGE THE MEANING OF AN ALREADY ESTABLISHED CONCEPT!

CheckBox

Let’s continue with the CheckBox control. If a Border is something that surrounds something else, a checkbox is something that we have come to know 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 a nullable bool, since it can be:

  • Checked
  • Unchecked
  • Undetermined

Wow, that changes everything. The undetermined state comes from having a nested collection of checkboxes, where some are checked and some are unchecked. I think that this nesting should not affect the checked property. Instead, this property should reflect on whether or not the user has checked the box (which is what 99% of the ux scenarios will be like) and instead have an optional property to check the state of the nested checkboxes.

If Microsoft wanted to change this convention, they should have introduced a new UI control (it could even inherit a regular CheckBox). It could have been called:

  • HierarchicalCheckboxCollection
  • NullableCheckBox
  • FuzzyCheckBox
  • CheckBoxGoodForSwedishDecisionMakersWhoDoNotWantToMakeADecision
  • NotReallyACheckBox

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

WPF CheckBox enemy bonus content

After publishing this post, I decided that you deserve a gift when you decide to join me in my war against WPF. How about a nice extension method to the CheckBox:

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

Enjoy 🙂

Conclusion

Wow, that felt good. Please provide me with more examples, and maybe in a not too distant future, we can have a clean WPF framework that conforms to the conventions the rest of the world uses.

Wouldn’t that be something?