I proudly present to you the seventh in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stumbled on.

In Slippery When Wet #6: XPath and the Default Namespace I already ran in some problems with XML in .NET. And I’ve done it again!

For a dynamically built User Interface I’ve bound some controls to a XDocument tree that contained the data and the description of the types. The first controls (TextBox and a numeric Control) worked perfectly, so I was confident that the next controls would just be a routine work. So the next control I wanted to use was the ComboBox.

The data was shown as expected, but after changing the selection the new data was not saved. I’ve tried several changes in the binding (adding explicit two-way binding, setting the UpdateSourceTrigger to PropertyChanged) but the data was not updated when the selection changed. I’ve asked some guys in the office with more WPF experience, but they also saw no reason why the binding didn’t work. Even adding a Converter to check if the data types were not compatible gave me no clue. I’ve also asked on Stack Overflow but got no solution for my problem.

After asking Dr. Google the right question I’ve found these two entries in the MSDN Forum:
MSDN Forum: ComboBox that binds to XElement breaks in .NET 4 and
ComboBox and DataGridComboBoxColumn two-way data binding broken in .NET 4 with XLinq for the SelectedItem/SelectedItemBindings property
which guided me to the Hot Fix from Microsoft (The „TwoWay“ binding does not reflect changes when the property path of the binding refers to the Attribute or Element method of an XElement object in a .NET Framework 4.0-based WPF application).

So it looks like I’ve done it right this time but Microsoft didn’t. So now I’m waiting for getting the Hot Fix installed on my System to check if it works now.