views:

481

answers:

3

Previously, I had a class that wrapped an internal System.Collections.Generic.List<Item> (where Item is a class I created). The wrapper class provided several collection-level properties that provided totals, averages, and other computations on items in the list. I was creating a BindingSource around this wrapped List<> and another BindingSource around my class and was able to get at the Items in the wrapped list through the first BindingSource and the collection-level properties of the wrapper class using the second.

A simplified example looks like:

public class OldClass()
{
  private List<Item> _Items;

  public OldClass()
  {
    _Items = new List<Item>();
  }

  public List<Item> Items { get { return _Items; } }

  // collection-level properties
  public float AverageValue { get { return Average() } }
  public float TotalValue { get { return Total() } }
  // ... other properties like this

}

With the binding sources created in this way:

_itemsBindingSource = new BindingSource(oldClass.Items);
_summaryBindingSource = new BindingSource(oldClass);

Recently, I tried to change this class to be derived from System.Collections.Generic.List<Item> instead of keeping a wrapped List<> member. My hope was to get rid of the extra wrapper layer and use only one BindingSource instead of two. However, now I find that I cannot get at the properties that apply to all items in the list (such as AverageValue) when I do data binding. Only the properties of list items are available.

Am I forced to go back to using a wrapped List<> of Items? Or is there a way that I can get at both the properties of Items stored my new class as well as the properties that apply to the collection itself?

A: 

The problem here is that you want to use your one class for two completely different purposes (in terms of bindings).

Example: The "AverageValue" property doesn't make sense to be on each item, because it's a global property that spans all items.

Either way, I'm guessing that your _itemsBindingSource is for a ComboBox or something, and that your _summaryBindingSource is for a PropertyGrid (or something like that).

What you could do, that might work in your situation (I can't be certain because I don't know what you are actually doing) is this:

1) Make your "OldClass" implement IEnumerable... and in that, simply return the enumeration from the list. That will give you the ability to bind to "oldClass" instead of "oldClass.Items".

2) Make the "public List Items" a field, instead of a property... or add the "Browsable(false)" attribute so it won't get bound to the PropertyGrid (this is a guess as it's unclear what you're using these bindings for).

Timothy Khouri
+2  A: 

The system treats anything that implements IList (or IListSource) as a container, rather than an item. As such, you cannot bind to properties of anything that implements IList. As such, encapsulation (i.e. what you already have) is the best approach if you want to be able to bind to properties of the container.

However, you should note that many bindings support dot-notation in the source - i.e. either binding to "Items.SomeProperty", or setting the auxiliary property (typically DataMember) to specify sub-lists.

This allows you to have a single BindingSource, and have different controls bound to different levels in the hierarchy - i.e. you might have a TextBox bound to AverageValue, and a DataGridView (with the same DataSource) that has DataMember="Items".

Marc Gravell
A: 

Instead of creating a wrapper class around your List, have you considered creating an extension class (assuming you're using C# 3)

public static class MyExtensions
{
    public static float GetAverage(this List<Item>)
    {
        // implementation
    }

    public static float GetTotal(this List<Item>)
    {
        // implementation
    }
}

Of course, your properties become method calls (maybe C# 4 will fix this), but you would eliminate the wrapper entirely.

Keltex