Home > WPF, WPF Controls > ComboBox SelectedItem and ItemsSource: Order Matters

ComboBox SelectedItem and ItemsSource: Order Matters

January 14th, 2009

A co-worker of mine had a strange issue with a bound combo box that looked like this: 

  ItemsSource="{Binding Path=Order.Store.Users, ElementName=me, Mode=Default}"
  SelectedItem="{Binding Path=Order.ParentUser, ElementName=me, Mode=Default}"
  DisplayMemberPath="UserName" />


As we could observe at runtime, selecting an item in the combo box properly updated the underlying ParentUser property. Furthermore, we could easily exchange the data context (Order dependency property) in order to edit different items.

However: As soon a the editor control that contained the combo box was unloaded, the ParentUser property of the currently edited Order was set to null, so all previously made adjustments were lost.

The reason behind this behavior seems to be the fact that both ItemsSource and SelectedItem are bound to the same dependency property: Apparently, when Order is set to null during unloading, WPF realizes that the ItemsSource is no longer valid, and therefore clears the SelectedItem, to which the combo box still appears to hold a reference at this moment – which brings it down to a question of proper coercion. Or maybe not – the reason behind this is not entirely clear to me.

However: Changing the declaration order of SelectedItem and ItemsSource fixes the problem:

  SelectedItem="{Binding Path=Order.ParentUser, ElementName=me, Mode=Default}"
  ItemsSource="{Binding Path=Order.Store.Users, ElementName=me, Mode=Default}"
  DisplayMemberPath="UserName" />


And yes: This does feel like a dirty hack.

Author: Categories: WPF, WPF Controls Tags: ,
  1. Mircea Deliu
    January 27th, 2009 at 11:45 | #1

    Same thing here.

    Dose anyone have an explanation for this strange behavior?

  2. Scott Rogers
    June 10th, 2009 at 12:20 | #2

    Wow… I wasted alot of time cursing WPF and trying to find a solution to the problem you describe above. Thankfully your fix addresses the issue, but I agree this does feel like a dirty hack.

    Whilst .NET and particularly wpf xaml is code-order-sensitive, incorrectly ordered code (leading to missing references) is usually picked up as a compile-time, or run-time exception. This however is not and cannot be desired behviour!

  3. Chris Walker
    July 3rd, 2009 at 19:25 | #3

    OMG! Thanks for posting this! I was having the same problem and couldn’t figure out why. It still doesnt’ make sense why the order of the properties in the XAML should make sense, but at least I have a solution to the problem without having to code gobs of properties to store and re-assign old values!

    Again, Thanks a ton!

    And Yes…It most definitely feels like a dirty hack, but it works!

  4. _
    March 17th, 2010 at 14:48 | #4


  5. Maik
    June 15th, 2010 at 10:01 | #5

    it’s not only SelectedItem. With Text or SelectedValue are the same problems…

  6. August 9th, 2010 at 16:53 | #6

    you have to remember that WPF doesn’t just watch the last field/property of the binding path, it watches the entire path. So if order is ripped out from under it, it will update the binding for the items source. In your case, you pulled that out, the current selected item is no longer in the ItemSource (not is in fact) and so the selected item is updated also. Yes, what you did was a hack. You should instead disconnect your data context/viewmodel from the view during shutdown.

  7. Dan
    December 13th, 2011 at 14:33 | #7

    Wow!!! This is AWESOME… I was about to give up on binding the combobox in a particular app because of this… yes it is dirty, but I have “IsEditable” set to TRUE, so in my believe it should not change my selected value if I kill the ItemsSource list.

  8. Ozgur Karahan
    January 16th, 2012 at 01:17 | #8

    I had exactly same problem and i couldn’t understand where there was a problem. It is really strange as a behavior.
    Thanks for the solution, it works fine.

  1. July 14th, 2010 at 14:58 | #1
  2. February 23rd, 2011 at 10:24 | #2