[.NET 2.0+] Custom Typed Collections and Data-binding Support

[jmcilhinney]

VB version here.

If we want to use a standard collection in .NET 2.0 or later we use a generic List. If we want to create our own strongly-typed collection we used to have to inherit CollectionBase. That was a pain because, in the days before generics, we used to have to define all the type-specific members ourselves. We would inherit members like Clear and RemoveAt from CollectionBase because they didn't depend on the type of the items. Members like Item and Add though, whose return type or parameter type(s) depends on the type of the items, were left up to us. Since the introduction of generics, life has become much easier. To create a strongly typed collection with all the standard functionality we simply inherit the generic Collection class and that's it:

public class ThingCollection : System.Collections.ObjectModel.Collection<Thing>
{
}

All the standard functionality is inherited from the base class so we don't need to add any members of our own. That said, if we want to provide custom functionality then we can add our own members. The generic Collection class provides methods that you can override to process items as they are added and removed from the collection. One common use for those members is custom validation, e.g.

public class ThingCollection : System.Collections.ObjectModel.Collection<Thing>
{
    protected override void InsertItem(int index, Thing item)
    {
        bool duplicateID = false;
 
        foreach (Thing existingItem in this.Items)
        {
            if (item.ID == existingItem.ID)
            {
                duplicateID = true;
                break;
            }
        }
 
        if (duplicateID)
        {
            // Don't add an item with a duplicate ID.
            throw new ArgumentException("An item with the specified ID already exists");
        }
        else
        {
            // Allow the item to be added.
            base.InsertItem(index, item);
        }
    }
 
    protected override void SetItem(int index, Thing item)
    {
        bool duplicateID = false;
 
        for (int existingIndex = 0; existingIndex < this.Count; existingIndex++)
        {
            // Ignore the existing item at the index being set because it is being replaced.
            if (existingIndex != index && item.ID == this.Items[existingIndex].ID)
            {
                duplicateID = true;
                break;
            }
        }
 
        if (duplicateID)
        {
            // Don't add an item with a duplicate ID.
            throw new ArgumentException("An item with the specified ID already exists");
        }
        else
        {
            // Allow the item to be added.
            base.SetItem(index, item);
        }
    }
}

So, that's nice and easy. Now, with regards to data-binding, you can quite easily bind either a generic List or your own strongly-typed collection to controls in your UI and the data they contain will be displayed. That's because they all implement the IList interface, which is all data-binding requires. The problem is, if you intend to make changes to your collection in code, like adding or removing items or editing properties of the items, then you'll be disappointed if you expect to see those changes reflected in the UI.

That's because the bound control is not implicitly aware of any changes taking place in the data source. It must be explicitly notified of changes in order to know that it should update its display. In order to provide such notification your data source must implement the IBindingList interface, which neither the generic List nor generic Collection class does. The easy way out of this is to bind your data to a BindingSource and then bind that to the control(s). You can then call ResetCurrentItem, ResetItem or RestBindings on the BindingSource to raise its ListChanged event and thereby notify the bound control to update.

That's all well and good, but what if the changes to the collection are occurring in code that can't see the BindingSource, like a business logic layer? In that case you need your collection to implement IBindingList itself. You could do that from scratch but you don't actually need to. Instead of deriving your collection directly from the generic Collection class, you can instead inherit the generic BindingList class, which itself inherits Collection and adds an IBindingList implementation. Again, you don't have to add any code of your own if you only want the standard functionality:

public class ThingCollection : System.ComponentModel.BindingList<Thing>
{
}

Now your collection will raise its ListChanged event automatically whenever you add, insert, set or remove an item or clear the list. Any bound controls will automatically update as a result.

Now, that's fine for making changes to the list but what about if you make changes to items that are already in the list? Bound controls will not update automatically because the BindingList doesn't raise a ListChanged event automatically because it doesn't inherently know when an item changes. This is where you need to do a little bit of work.

What needs to happen is that your item class needs to raise an event when a property value changes, e.g.

public class Thing
{
    private string _name;
 
    public string Name
    {
        get
        {
            return this._name;
        }
        set
        {
            if (this._name != value)
            {
                this._name = value;
                this.OnNameChanged(EventArgs.Empty); 
            }
        }
    }
 
    public event EventHandler NameChanged;
 
    protected virtual void OnNameChanged(EventArgs e)
    {
        if (this.NameChanged != null)
        {
            this.NameChanged(this, e);
        }
    }
}

Your typed collection can now handle that event and raise its own ListChanged event to notify any bound controls of the change:

public class ThingCollection : System.ComponentModel.BindingList<Thing>
{
    private void HandleNameChanged(object sender, EventArgs e)
    {
        this.OnListChanged(new ListChangedEventArgs(ListChangedType.ItemChanged,
                                                    this.Items.IndexOf((Thing)sender)));
    }
}

Note that you specify ItemChanged as the change type.

Now, that method isn't going to handle any events on its own. We need to attach it to the NameChanged event of each item as it gets added to the list. We also need to make sure we detach when an item gets removed from the list. For that we need to override methods inherited from the Collection class, much as we did for the validation earlier:

public class ThingCollection : System.ComponentModel.BindingList<Thing>
{
    protected override void InsertItem(int index, Thing item)
    {
        base.InsertItem(index, item);
 
        // Attach the event handler to the item being added.
        item.NameChanged += new EventHandler(HandleNameChanged);
    }
 
    protected override void SetItem(int index, Thing item)
    {
        // Remove the event handler from the item being removed.
        this.Items[index].NameChanged -= new EventHandler(HandleNameChanged);
 
        base.SetItem(index, item);
 
        // Attach the event handler to the item being added.
        item.NameChanged += new EventHandler(HandleNameChanged);
    }
 
    protected override void RemoveItem(int index)
    {
        // Remove the event handler from the item being removed.
        this.Items[index].NameChanged -= new EventHandler(HandleNameChanged);
 
        base.RemoveItem(index);
    }
 
    protected override void ClearItems()
    {
        // Remove the event handler from all existing items.
        foreach (Thing item in this.Items)
        {
            item.NameChanged -= new EventHandler(HandleNameChanged);
        }
 
        base.ClearItems();
    }
 
    private void HandleNameChanged(object sender, EventArgs e)
    {
        this.OnListChanged(new ListChangedEventArgs(ListChangedType.ItemChanged,
                                                    this.Items.IndexOf((Thing)sender)));
    }
}

Another useful feature of the IBindingList interface is simple sorting support, i.e. sorting by a single column/property. By adding such support to your typed collection you enable, for instance, a user to click a column header in a DataGridView bound to your collection and have the data sorted automatically. I'll look at that in the next instalment. Stay tuned!

[jmcilhinney]

I've attached a test project containing the final Person and PersonCollection classes used in this example, but I'll post code snippets along the way to highlight certain points.

As I mentioned in the previous post, in order to support sorting when bound a collection must implement the IBindingList interface. As I also mentioned, the easiest way to implement the IBindingList interface is to inherit the BindingList class:

public class PersonCollection : System.ComponentModel.BindingList<Person>
{
}

Now, in order to support sorting in our collection we must do three things:

1. Override the SupportsSorting property and return True;
2. Override the ApplySortCore method and implement our sort; and
3. Override the RemoveSortCore method and remove our sort.

using System.ComponentModel;
 
public class PersonCollection : System.ComponentModel.BindingList<Person>
{
    protected override bool SupportsSortingCore
    {
        get
        {
            return true;
        }
    }
 
    protected override void ApplySortCore(PropertyDescriptor prop, ListSortDirection direction)
    {
        base.ApplySortCore(prop, direction);
    }
 
    protected override void RemoveSortCore()
    {
        base.RemoveSortCore();
    }
}

Next, if we're going to sort the items in our collection, we need some way to compare them. If the item class is under your control then you can make it implement the IComparable interface and then items can be compared directly. That's not much good if we want to sort by different properties at different times though. In that case we need to define a new class that implements the IComparer interface. It does much the same job as IComparable but from outside the objects instead of from inside.

Data-binding makes heavy use of PropertyDescriptors. As the name suggests, A PropertyDescriptor is an object that describes a property, which is why only properties can be bound and not fields. As such, our IComparer implementation should also be based on PropertyDescriptors:

private class PersonComparer : System.Collections.Generic.IComparer<Person>
{
    private PropertyDescriptor prop;
    private ListSortDirection direction;
 
    public PersonComparer(PropertyDescriptor prop, ListSortDirection direction)
    {
        this.prop = prop;
        this.direction = direction;
    }
 
    public int Compare(Person x, Person y)
    {
        // Get a value that indicates the relative positions of the values of the specified property.
        int result = ((IComparable)this.prop.GetValue(x)).CompareTo(this.prop.GetValue(y));
 
        // If the sort order is descending...
        if (this.direction == ListSortDirection.Descending)
        {
            // ...reverse the relative positions.
            result = -result;
        }
 
        return result;
    }
}

Note that this class is declared Private because, in the example, I've declared it inside the PersonCollection class. That's the only place it gets used so it makes sense.

Now, how does this class work? You create an instance by specifying the property you want to compare by, as a PropertyDescriptor, and a sort direction. Obviously the relative positions of the two objects will be reversed if the sort direction is reversed. You can pass any two Person objects to this instance's Compare method and it will provide a value that indicates their relative order.

Notice that I cast the first property value as type IComparable, which is done to access its CompareTo method in order to compare it to the other property value. This requires that the type of the property actually does implement IComparable. This will always be the case for primitive types like String and Integer, which are always directly comparable, but will not be the case for more complex types. For instance, you wouldn't sort a collection of DataTables by their Rows properties because it doesn't make sense to compare two DataRowCollections and get a relative order.

Now, when sorting a list of items, such comparisons are performed repeatedly in order to shuffle pairs of items into the correct order until all items are ordered as desired. Our ApplySortCore method must do just that:

protected override void ApplySortCore(PropertyDescriptor prop, ListSortDirection direction)
{
    Person[] items = new Person[this.Items.Count];
 
    this.Items.CopyTo(items, 0);
    Array.Sort(items,
               new PersonComparer(prop,
                                  direction));
 
    for (int index = 0; index < items.Length; index++)
    {
        this.Items[index] = items[index];
    }
 
    this.OnListChanged(new ListChangedEventArgs(ListChangedType.Reset, 0));
}

In this method we create an array containing all our items, sort it using an instance of our IComparer, then replace the existing items with this sorted set. They are the same items but in a different order. There may well be more efficient ways to implement the sort but that will do for this example.

Note that this ApplySortCore method is what gets invoked when your collection is bound to a DataGridView and the user clicks a column header. This may seem a little strange because the method is declared Protected, so it should not be accessible outside the class. In fact, the ApplySortCore method is NOT accessible outside the class. ApplySortCore is an explicit implementation of the IBindingList.ApplySort method though. That means that you cannot call ApplySortCore on a PersonCollection object, but if you cast it as type IBindingList and call ApplySort then you will invoke that method. This is exactly what happens when your collection is bound.

This all allows you to sort your collection when bound to your UI. It does make sorting a collection in code somewhat cumbersome though. You'd have to create a PropertyDescriptor, cast the collection as type IBindingList and call ApplySort. To avoid this, I've added a Sort property to the PersonCollection class in the attached project. It works much like the Sort property of the BindingSource and DataView classes, but it only supports one property at a time.

When you run the attached project you'll see a small PersonCollection bound to a DataGridView. Try clicking the column headers and watch the data get sorted. Now try entering a sort clause in the TextBox and clicking the Sort button. You can specify any of the three property names and, optionally, a direction. If the direction is omitted then ascending is assumed. Note that the property name is case sensitive but the direction is not. Examples of valid clauses are "LastName", "FirstName ASC" and "ID DESC".

One final point to note. This implementation is not perfect. For instance, if you sort the collection and then add a new item it will not take into account the current sort order. This may be desirable but, in case it's not, I'll look at fixing that in the next installment. Stay tuned!

[jmcilhinney]

For this example I used the project from the previous post as a starting point, modified it and I've attached the new version to this post. This new version addresses the issue I mentioned at the end of the previous post. Now, if you sort the grid, either by clicking a column header or the Sort button, and then you edit the data, the grid will resort itself automatically. How is this achieved? Read on.

The first step was to make the Person class implement the INotifyPropertyChanged interface:

using System.ComponentModel;
 
public class Person : System.ComponentModel.INotifyPropertyChanged
{
    private int _id;
    private string _firstName;
    private string _lastName;
 
 
    public int ID
    {
        get
        {
            return this._id;
        }
        set
        {
            if (this._id != value)
            {
                this._id = value;
                this.OnPropertyChanged(new PropertyChangedEventArgs("ID"));
            }
        }
    }
 
    public string FirstName
    {
        get
        {
            return this._firstName;
        }
        set
        {
            if (this._firstName != value)
            {
                this._firstName = value;
                this.OnPropertyChanged(new PropertyChangedEventArgs("FirstName"));
            }
        }
    }
 
    public string LastName
    {
        get
        {
            return this._lastName;
        }
        set
        {
            if (this._lastName != value)
            {
                this._lastName = value;
                this.OnPropertyChanged(new PropertyChangedEventArgs("LastName"));
            }
        }
    }
 
 
    public Person(int id, string firstName, string lastName)
    {
        this._id = id;
        this._firstName = firstName;
        this._lastName = lastName;
    }
 
 
    /// <summary>
    /// Occurs when a property value changes.
    /// </summary>
    public event PropertyChangedEventHandler PropertyChanged;
 
 
    /// <summary>
    /// Raises the PropertyChanged event.
    /// </summary>
    protected virtual void OnPropertyChanged(PropertyChangedEventArgs e)
    {
        if (this.PropertyChanged != null)
        {
            this.PropertyChanged(this, e);
        }
    }
}

Now a Person object will notify any listeners each time one of its property values changes. This has two effects:

1. If we edit a property value of a Person object in code, that change will be reflected automatically in any bound controls. That's because bound controls listen for the PropertyChanged event of the items they're bound to.

2. Our collection knows when a property value of an item changes so it can resort itself if necessary.

The second effect is what we're specifically interested in here. In order to implement this we must first add an event handler to the PersonCollection class to handle the PropertyChanged event of its items:

/// <summary>
/// Handles the PropertyChanged event for all items in the collection.
/// </summary>
/// <param name="sender">
/// The item whose property value has changed.
/// </param>
/// <param name="e">
/// Contains the name of the property whose value has changed.
/// </param>
private void Person_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
    if (this._sortProperty.Name == e.PropertyName)
    {
        // A value has changed in the property by which the items are sorted so resort the collection.
        this.ApplySortCore(this._sortProperty, this._sortDirection);
    }
}

Now, this method is supposed to handle the PropertyChanged event for all the items in the collection and none that aren't. This doesn't happen automatically. We need to attach the event handler as an item is added to the collection and, just as importantly, we need to detach the event handler as an item is removed from the collection:

/// <summary>
/// Removes all elements from the collection.
/// </summary>
protected override void ClearItems()
{
    // Detach event handlers from all items.
    foreach (Person item in this.Items)
    {
        item.PropertyChanged -= new PropertyChangedEventHandler(Person_PropertyChanged);
    }
 
    base.ClearItems();
}
 
/// <summary>
/// Inserts the specified item in the list at the specified index.
/// </summary>
protected override void InsertItem(int index, Person item)
{
    base.InsertItem(index, item);
 
    // Attach event handlers to the item being added.
    item.PropertyChanged += new PropertyChangedEventHandler(Person_PropertyChanged);
}
 
/// <summary>
/// Removes the item at the specified index.
/// </summary>
protected override void RemoveItem(int index)
{
    // Detach event handlers from the item being removed.
    this.Items[index].PropertyChanged -= new PropertyChangedEventHandler(Person_PropertyChanged);
 
    base.RemoveItem(index);
}
 
/// <summary>
/// Replaces the item at the specified index with the specified item.
/// </summary>
protected override void SetItem(int index, Person item)
{
    // Detach event handlers from the item being removed.
    this.Items[index].PropertyChanged -= new PropertyChangedEventHandler(Person_PropertyChanged);
 
    base.SetItem(index, item);
 
    // Attach event handlers to the item being added.
    item.PropertyChanged += new PropertyChangedEventHandler(Person_PropertyChanged);
}

That looks after resorting when existing items are edited. We need only extend that slightly to resort the collection when new items are added:

/// <summary>
/// Inserts the specified item in the list at the specified index.
/// </summary>
protected override void InsertItem(int index, Person item)
{
    base.InsertItem(index, item);
 
    // Attach event handlers to the item being added.
    item.PropertyChanged += new PropertyChangedEventHandler(Person_PropertyChanged);
 
    if (this._sortProperty != null)
    {
        // Ensure that the collection maintains the correct sort order.
        this.ApplySortCore(this._sortProperty, this._sortDirection);
    }
}
 
/// <summary>
/// Replaces the item at the specified index with the specified item.
/// </summary>
protected override void SetItem(int index, Person item)
{
    // Detach event handlers from the item being removed.
    this.Items[index].PropertyChanged -= new PropertyChangedEventHandler(Person_PropertyChanged);
 
    base.SetItem(index, item);
 
    // Attach event handlers to the item being added.
    item.PropertyChanged += new PropertyChangedEventHandler(Person_PropertyChanged);
 
    if (this._sortProperty != null)
    {
        // Ensure that the collection maintains the correct sort order.
        this.ApplySortCore(this._sortProperty, this._sortDirection);
    }
}

Now, if the collection is currently sorted, it is resorted each time a new item is added.

To test this out, try running the attached project and click a column header to sort the grid by that column. Now try editing a cell in that column such that it would make the rows out of order. Note that when you navigate away from that cell the grid resorts to maintain correct order in the sorted column. Now try entering new values in the controls at the bottom of the form and hitting the Add button. Make sure that adding the new item at the bottom of the grid would make the rows out of order. Note that the grid resorts itself such that the new item is placed to maintain correct order in the sorted column.

Again, I should point out that this code has not been implemented in the most efficient way possible. I've used the easiest way to provide sorting but the best way would require some more work. For instance, when an item is added, at the moment it is added to the end of the collection and the grid will update, then the collection is resorted and the grid will update again. In this example you don't see a difference and there are so few items that everything happens quickly enough that it doesn't matter. With a larger number of items it might become apparent that the grid was refreshing twice. Ideally we would avoid updating the grid twice by ensuring that the new item is inserted at the correct index to begin with. I'll look at optimising this code at a later time. Stay tuned!

[Andy_P]

Outstanding. Many thanks for this.

[eliza_81]

First create a class that implements [IComparer] interface and define the [Compare] method.Following is the class that we will use for sorting Clients order by last name.
[VB.NET CODE STARTS]

Public Class ClientComparer
Implements IComparer

Public Function Compare(ByVal x As Object, ByVal y As Object) As Integer Implements System.Collections.IComparer.Compare
Dim objClientX As Client = CType(x, Client) ' Client is the class having FirtsName, LastName as properties
Dim objClientY As Client = CType(y, Client)

Dim sX As String = UCase(objClientX.LastName) ' comparision is made using the LAST NAME OF CLIENT
Dim sY As String = UCase(objClientY.LastName)

If sX = sY Then
Return 0
End If

If sX.Length > sY.Length Then
sX = sX.Substring(0, sY.Length)
If sX = sY Then
Return 1
End If
ElseIf sX.Length < sY.Length Then
sY = sY.Substring(0, sX.Length)
If sX = sY Then
Return -1
End If
End If

For i As Integer = 0 To sX.Length
If Not sX.Substring(i, 1) = sY.Substring(i, 1) Then
Return Asc(CType(sX.Substring(i, 1), Char)) - Asc(CType(sY.Substring(i, 1), Char))
End If
Next
End Function

End Class

[VB.NET CODE ENDS]

Hope it would answer your question.

[jmcilhinney]

Hope it would answer your question.

Um, there was no question. This is an example, in C#, of how to create a custom collection that supports data-binding. A VB example of how to sort a collection isn;t really relevant to this thread.