 Monday, January 10, 2005
Use BindingList for data bound collections
I finished up another chapter on my book last night. This one was on creating data bound custom business objects and collections. I won't try to reiterate the entire chapter here, but I will pass along one of the key take-aways: use BindingList<T> for custom business object collections if you want to provide rich data binding capabilities in Windows Forms 2.0.
The BindingList<T> generic type is defined in the System.ComponentModel.Collections.Generics namespace in Beta 1, but is getting refactored into System.ComponentModel in Beta 2. Basically this type allows you to create strongly typed collections that implement IBindingList (partially), IList, ICollection, and IEnumerable, with a single line of code:
BindingList<Customer> CustomerCollection = new BindingList<Customer>();
By doing just this, you get a collection that works fine with both Windows Forms and ASP.NET data binding mechanisms, including two-way data binding (presentation and editing) support in Windows Forms, and also will fire ListChanged events whenever items in the collection are added, removed, or replaced. If you want to support events when the contained objects are edited, you will need to implement the INotifyPropertyChanged interface on the object type definition itself (this interface is named IPropertyChanged in Beta 1).
Additionally, if you want to support sorting and searching on the collection, all it takes it to derive a class from your BindingList<T> parameterized type, and override a few base class methods and properties. For example, you could declare a Customer collection and provide searching capability with something like the following:
public class CustomerCollection : BindingList< Customer> { protected override bool SupportsSearchingCore { get { return true; } }
protected override int FindCore(PropertyDescriptor property, object key)
{
for (int i = 0; i < Count; i++)
{
Customer c = this[i];
if (property.GetValue(c) == key)
{
return i;
}
}
return -1; // Not found
}
}
Very powerful stuff. Sorting is a little more involved, but follows the same process. Override the sort related properties, and provide a sorting algorithm in the ApplySortCore override and you are off and running.
So much easier and more powerful than the old derive from CollectionBase approach. You get type safety, alot of additional functionality, and the efficiency of generic types.
|
| July, 2008 (1) |
| June, 2008 (2) |
| May, 2008 (2) |
| April, 2008 (3) |
| February, 2008 (6) |
| January, 2008 (3) |
| December, 2007 (1) |
| November, 2007 (1) |
| October, 2007 (5) |
| September, 2007 (1) |
| July, 2007 (3) |
| June, 2007 (8) |
| April, 2007 (2) |
| March, 2007 (4) |
| February, 2007 (1) |
| December, 2006 (2) |
| November, 2006 (9) |
| October, 2006 (5) |
| September, 2006 (3) |
| August, 2006 (2) |
| July, 2006 (4) |
| June, 2006 (5) |
| May, 2006 (10) |
| April, 2006 (4) |
| March, 2006 (2) |
| February, 2006 (12) |
| January, 2006 (7) |
| December, 2005 (2) |
| November, 2005 (15) |
| October, 2005 (6) |
| September, 2005 (7) |
| August, 2005 (3) |
| July, 2005 (10) |
| June, 2005 (11) |
| May, 2005 (7) |
| April, 2005 (8) |
| March, 2005 (6) |
| February, 2005 (2) |
| January, 2005 (6) |
| December, 2004 (3) |
| November, 2004 (5) |
| October, 2004 (2) |
| September, 2004 (5) |
| August, 2004 (13) |
| July, 2004 (6) |
| June, 2004 (14) |
| May, 2004 (17) |
| April, 2004 (12) |
| March, 2004 (8) |
| February, 2004 (10) |
| January, 2004 (14) |
| December, 2003 (9) |
| November, 2003 (13) |
| October, 2003 (3) |
Sign In
|