Binding for SelectedItem in ComboBox-based custom editor

Hi, this is probably a gap in my WPF knowledge...anyways, I have enclosed a sample that reproduces a problem I am having with data binding.  There are two very simple custom editors, both based on ComboBox. The first uses an XmlDataProvider as its ItemsSource, the second uses an ObjectDataProvider with a public static method that retruns a list<string>.  Both  have SelectedItem="{Binding Value}".

But one of them works, with respect to binding, and one of them doesn't.   If you run the sample and select Object 1 and sets its City and Country, then select Object 2, then go back to Object 1, the City is lost but the Country is not.....

Can you see what I am missing?

Thanks,

Paul

 

The problem is that the CityPicker ItemsSource binding is, despite appearances, returning a set of XmlElement objects.  The ComboBox is making these look like strings, but they're not.  So when the two-way binding sets Value to the SelectedItem, it is actually setting Value to "System.Xml.XmlElement" (because the target type is string, and this is the stringification of an XmlElement).  (You can see this by putting a debugger on the City property setter, or by adding a button to display the contents of one of the objects.)  When you go away from an object and come back to it, the ComboBox looks for a City called "System.Xml.XmlElement", fails to find one, and displays no selection.

The solution is to change the ComboBox declaration to use SelectedValue instead of SelectedItem.

<ComboBox
  ItemsSource="{Binding Source={StaticResource Cities}, XPath=/Cities/City}"
  SelectedValue="{Binding Value}" />

Thanks, I tried that and it had no effect. I did set breakpoints on the getter/setter and noticed that the setter for City is never called, so maybe the type incompatibility is causing the setter to never be called?

Hmm, it's definitely working for me.  I did try a number of changes before reducing it to the SelectedValue one but perhaps there was something else I did that I lost track of.  I've attached my working version so you can try it out and have a compare with yours.  Let me know if it still doesn't work for you.

Your City setter was/is being called.  (You can verify this by dumping the object data -- see the Show buttons I added.)  The reason it doesn't look like it in the debugger is that you're using C# 3 automatic properties, which don't allow you to set breakpoints, curse them.  Or rather, they allow you to *set* breakpoints, they just ignore them.  It is very annoying and misleading and I usually find myself having to convert automatic properties to "manual" ones for precisely this reason... sigh...

Thanks, Ivan, good advice all of it, though I did "unpack" the Dummy properties to observe the breakpoints. The City Setter is not being called....  curious if it is for you, I've attached a screen shot from your Example running that might be different from what you are observing, let me know....

Hmm, it looks like my proposed solution only works under .NET 3.5 SP1.  Not sure why this should be.  I will investigate further and let you know.

It appears that a workaround is to initialise City to String.Empty (or any other value) instead of null.  I am still investigating why a null value causes a problem.

I have not been able to locate the problem; however, I have determined that you can get around it by adding a converter to the SelectedValue binding.  The converter just needs to check for null and return String.Empty when converting in the forward direction, and pass through in the backward direction:

    public class DenullifyingConverter : IValueConverter
    {
      public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
      {
        return (value == null ? String.Empty : value);
      }

      public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
      {
        return value;
      }
    }

I realise this is not ideal and I will leave the bug open, but at the moment I don't have a solution and I believe the value converter workaround should suffice for most scenarios (as it doesn't intrude into your existing objects).  If this is not feasible in your real application then let me know and I will see what I can come up with.

Obviously another possibility to consider is migrating to WPF 3.5 SP1, which appears to fix whatever the underlying cause is, though this is obviously not something you would undertake lightly, and I would stress that the grid is intended to run on 3.0 SP1 and that moving to 3.5 SP1 is only a suggestion for dealing with the specific issue of XML data and nulls.