How to update a WPF ComboBox when assigning an object as its SelectedItem?

Question

I have a ComboBox which has its ItemsSource bound to an ObservableCollection<CustomObject> where CustomObject has a few properties.

Sample class:

public class CustomObject : INotifyPropertyChanged
{
    public string Property1 { /*...omitted for brevity...*/ }
    public string Property2 { /*...omitted for brevity...*/ }
    public string Property3 { /*...omitted for brevity...*/ }
}

The SelectedItem property of my ComboBox is bound to a CustomObject property which appears in a DataGrid row.

Sample class:

public class DataGridEntry : INotifyPropertyChanged
{
    public CustomObject Column1 { /*...omitted for brevity...*/ }
    public string Column2 { /*...omitted for brevity...*/ }
    public string Column3 { /*...omitted for brevity...*/ }
}

I create the ObservableCollection<CustomObject> during the initialization of my window and then set the data context of my DataGrid to an ObservableCollection<DataGridEntry>.

My objective is to load initial values into my DataGrid, but I do not know how to make the ComboBox realize that the CustomObject specified can be found in its ItemsSource, and consequently, the ComboBox does not render a SelectedItem.

Here is how I load the initial values:

ObservableCollection<DataGridEntry> entries = new ObservableCollection<DataGridEntry>();
MyWindow.DataContext = this;
entries.Add(new DataGridEntry(new CustomObject("val1", "val2", "val3"), "col2", "col3");

Do you know how I make the ComboBox set its SelectedItem property like this? If I change my code so that DataGridEntry works only with string properties, then the ComboBox renders the SelectedItem after initializing as I expect. For reference types, it is not working though.

In case it is needed, this is how I bind the data to the Combobox:

<ComboBox ItemsSource="{Binding RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type Window}}, Path=DataContext.CustomObjectsCollection}" SelectedItem="{Binding Column1, UpdateSourceTrigger=PropertyChanged}"/>

EDIT:
In case it is not clear, the ObservableCollection<CustomObject> contains an element which is instatiated the same as above: new CustomObject("val1", "val2", "val3");

I suspect that the ComboBox doesn't realize that the two CustomObjects are equivalent. And because of this suspicion, I overrode the Equals and GetHashCode functions for CustomObject, with no success. Apparently, the ComboBox has no problem detecting equality for non-reference data types such as strings. Thanks for the help! :)

What is "this" when you assign the DataContext? It should be pretty simple: Create a ViewModel that holds a collection ObservableCollection and also a ObservableCollection. Next, bind the ComboBox ItemsSource to the collection of CustomObjects, and its SelectedItem to the DataGrid's SelectedItem.Column1 (where Column1 is the CustomObject). Last, set the DataGrid's ItemsSource to the collection of DataGridEntries. Of course... you know you can put a ComboBox *inside* your data grid right? — Alan, Jul 15 '14 at 21:20
I've omitted my `DataContext` for simplicity. In actuality, I have a wrapper class which holds those collections as properties. And I set the `DataContext` of the main window to point to an instance of that wrapper. I believe the problem lies within the equality of the `CustomObject` added to the `DataGridEntry`, and the respective `CustomObject` in the collection. I suppose I forgot to mention that the `ObservableCollection` contains a `CustomObject` which is instatiated the same as the one inserted into the `DataGrid`: `new CustomObject("val1", "val2", "val3")` — Nicholas Miller, Jul 15 '14 at 22:17
It seems like it might be better for the CustomObjects with the same values to be in fact the same object? — Alan, Jul 16 '14 at 04:41

score 4 · Answer 1 · answered Jul 16 '14 at 08:46

4

Bear in mind that GetHashCode() and Equals() work on Object type comparison (i.e. your ObservableCollection<T> would need to be for Object type. )

For a stronger typed override, you should implement IEquatable<T> - this should allow the combobox to compare items when setting the SelectedItem property.

answered Jul 16 '14 at 08:46

toadflakz

7,764
1
27
40

Seems like what I'm looking for. I'll go ahead and give it a shot. – Nicholas Miller Jul 16 '14 at 12:04
Awesome it worked! Apparently I also didn't notice I had the incorrect property name for my binding. But IEquatable did indeed allow the `CustomObjects` to be compared properly by the `ComboBox` – Nicholas Miller Jul 16 '14 at 12:41
After fixing my binding problem, I tested with only using `Object.Equals`, and the `ComboBox` updates correctly. What exactly is `IEquatable.Equals` responsible for? – Nicholas Miller Jul 16 '14 at 13:27
For performing an exact type-to-type comparison. For example, define a class with an ID property that's auto-populated with a GUID and a Name string property. You could write the `IEquatable.Equals` such that the method only compares the Name property. If you create two objects and give them both the Name value of "Sally", then `Object.Equals` returns false (different references) and `IEquatable.Equals` would return true. – toadflakz Jul 18 '14 at 11:17
Answer still valid today, in 2017. I especially like how this can be made per-type, with the code present in only the class it affects. For me, the problem showed up when I try to update an old WPF solution to EF6. Somewhere, equality must have been treated differently in the old version of WPF or EF4. – Göran Roseen Sep 27 '17 at 09:55

score 0 · Accepted Answer · edited May 23 '17 at 11:51

The ComboBox is using Object.Equals to determine equality. By default, this means that the ComboBox expects identical references when working with reference types. When working with value types, Object.Equals compares the values. Although String is not technically a value type, it has overridden Object.Equals to compare values.

Similar to String, the equality behavior can be overridden by defining a custom Equals method for the class type the ComboBox holds.

For the example in the original post, the Equals method should compare each property as such:

public class CustomObject : INotifyPropertyChanged
{
    //Include properties, constructor, and INotifyPropertyChanged interface members.

    public override bool Equals(object obj)
    {
        CustomObject test = obj as CustomObject;  //test=null if obj cannot be casted.
        if(test == null) return false; //Comparing null against non-null: FALSE
        else
        {   //Check if all properties are equal.
            return ((Property1.CompareTo(test.Property1) == 0) &&
                    (Property2.CompareTo(test.Property2) == 0) &&
                    (Property3.CompareTo(test.Property3) == 0));
        }
    }
}

Although the ComboBox will remain functional without it. It is a good idea to override Object.GetHashCode as well. This is out of the scope of this answer, however, a well documented implementation of this function can be found here:

What is the best algorithm for an overridden System.Object.GetHashCode?

Ideally here you would implement `Object.Equals` as you have up until your `else` statement. At which point you would call `IEquatable.Equals` as the implementation you are providing is type-specific and as the `IEquatable` documentation says on MSDN "Defines a generalized method that a value type or class implements to create a type-specific method for determining equality of instances." — toadflakz, Jul 18 '14 at 11:22
Could you please elaborate more? If all I do is move my else-block into `IEquatable.Equals`, and if I call `IEquatable.Equals` from `Object.Equals`, then the two become the same with the exception of the cast and null checks. I'm not entirely sure what this accomplishes since the `ComboBox` doesn't care about `IEquatable.Equals`. Does this have something to do with extending my class? — Nicholas Miller, Jul 18 '14 at 12:09
No, it has to do with that `Object.Equals` is not supposed to be a type-specific implementation whereas `IEquatable.Equals` is. You could call it a style preference but I like to keep the code segregated like this so that a type-inspecific method is in fact type-inspecific (as it's documented to be used like this). Also there's nothing wrong with calling the type-specific `IEquatable.Equals` from the type-inspecific `Object.Equals` once you've established that the objects are the same type. — toadflakz, Jul 18 '14 at 13:03

How to update a WPF ComboBox when assigning an object as its SelectedItem?

2 Answers2

Linked