WPF/Silverlight ListBox and equality checking

In WPF we bind collections of objects to ListBoxes and the like all the time – its part and parcel of the WPF development cycle but this is something that stung me recently.

I bound a collection of objects to the ItemsSource property as usual but the selection was odd.  Every time I selected an item the ListBox assumed that the first item was also selected and subsequent selections marked all previous selections as selected, also the SelectedIndex was always 0.  It took some time but I tracked it down to the way that ListBoxes use equality.

Something I didn’t know was that the objects that I was using had an overridden Equals method which was simply comparing a single string on the objects to determine if they were equal.  Because I only wanted a small subset of of the object I only populated those properties I needed along with the id of the object and not the string being compared.

The below shows an example of what I was doing.

public class MainViewModel : INotifyPropertyChanged
{
    private ObservableCollection foos;

    public ObservableCollection Foos
    {
        get
        {
            return foos;
        }
        set
        {
            foos = value;
        }
    }

    public MainViewModel()
    {
        this.Foos = new ObservableCollection();
        this.Foos.Add(new Foo { id = 1, Display = "First" });
        this.Foos.Add(new Foo { id = 2, Display = "Second" });
        this.Foos.Add(new Foo { id = 3, Display = "Third" });
        this.Foos.Add(new Foo { id = 4, Display = "Fourth" });
        this.Foos.Add(new Foo { id = 5, Display = "Fifth" });
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

public class Foo
{
    public int id { get; set; }

    public string Display { get; set; }

    public string FooCode { get; set; }

    public override bool Equals(object obj)
    {
        return FooCode == (obj as Foo).FooCode;
    }
}

As we can see I have no interest in the FooCode property and as a result don’t use it in my ViewModel.

The problem with this is that now the ListBox has no way of knowing if the objects are different as we have an overriding Equals method that implements value equality rather than reference equality and because the value is always going to be the same (as I don’t set it) then the ListBox will assume that every object is essentially the same object.

A simple change to include the FooCode property in each object in the collection solves this problem and gives us different values for equality testing.

A sample project with 2 lists displaying this different behaviour can be found here.

Advertisements

MVVM – The ‘Other’ ViewModel

Something that we regularly do at work is add additional properties to business objects that are only for use on the client (isDirty, HasChanged …etc).  We have always just added these to the business object directly and thought nothing of it, but after listening to a Hanselminutes interview with Laurent Bugnion I discovered the ‘other’ use for a ViewModel – wrapping client side business objects to expose new properties.  This is also useful in removing the overhead of viewing objects via a converter.

I have recently started looking at ASP.NET MVC as well and the way to pass things between controller and view is by using a ViewModel class.  This overload of the term had not translated into being useable in MVVM as well so what follows is a short, simple example of using a ViewModel to better model some data to fit a view.

Lets say we have a meeting object that we have extracted from a service and it is now ready to display on our client.  This business object has no real relation to them ORM version of the same object if we are correctly differentiating between them and client facing business objects so it has no in-built tracking to determine if it has changed and we don’t want to send it back to the service for updating if nothing has changed.  Our class looks like this.

public class Meeting
{
    public Meeting()
    {

    }
    public string Subject { get; set; }
    public string Location { get; set; }
    public DateTime StartTime { get; set; }
    public List<Person> Attendees { get; set; }
}

This is a very simple class to define our meeting but it has no way of knowing if it has changed and also the StartTime property is stored on the server as UTC but the client could be anywhere.

 

Taking the latter problem first you may be tempted to bind directly to the StartTime property of this object and use a converter to convert to the appropriate time zone based on the user culture (as I have done many times).  As for the problem with a meeting change, there has to be some way of telling an object that it has changed.  Both of these problems can be solved with a MeetingViewModel.  This is a VM that follows the decorator pattern and could be implemented as follows:

public class MeetingViewModel
    {
        private Meeting inner;
        public MeetingViewModel(Meeting m)
        {
            inner = m;
        }

        public Meeting Inner
        {
            get
            {
                return inner;
            }
        }

        public string Location
        {
            get
            {
                return inner.Location;
            }
            set
            {
                inner.Location = value;
            }
        }
        public DateTime StartTime
        {
            get
            {
                return inner.StartTime;
            }
            set
            {
                inner.StartTime = value;
            }
        }
        public List<Person> Attendees
        {
            get
            {
                return inner.Attendees;
            }
            set
            {
                inner.Attendees = value;
            }
        }

        public DateTime LocalStartTime
        {
            get
            {
                return inner.StartTime.ToLocalTime();
            }
            set
            {
                inner.StartTime = value.ToUniversalTime();
            }
        }

        public bool IsDirty { get; set; }
    }

Here we now have a nice property that sorts out the StartTime into a local time for us and a property that determines if this object has changed.  In your VM that controls your view you now operate on an object of type MeetingViewModel and all bindings are to this object.  When it comes time to save the object you simply need to check if you have set the dirty flag and if so extract the internal Meeting object using the get-only property and send it back to the service.

 

This is also a nice way of working with business objects that you have no control over such as from an external web service or third party library.  Once you start to understand the power of this approach over simply using converters you will find yourself writing VM’s for all of your business objects that you need to modify slightly on the client side when you need properties like the above or other bits of information like calculated properties.