Wrapping collections with ITypedList - part 2, the download
In part 1 of this post, I have explained what the purpose of those wrapper classes is that I have created, and why the structure is how it is. I’m making the source code of the library available with this post – use it as you see fit, but please note that I have done no production testing of this code, so don’t blame me if it breaks.
The download is here: Sturm.CollectionWrapping.zip (6 KB)
Now how do you use that thing? Basically you use code like this:
Now, depending on the type of list you wrap, the return value of the CreateWrapper method is actually of one of the following four types:
- TypedListWrapperBindingListT – this is used for BindingList<T> derived collections
- TypedListWrapperIBindingList – this is used for collections that implement IBindingList, but are not derived from BindingList<T>
- TypedListWrapperIListT – this is used for collections that implement IList<T>
- TypedListWrapperIList – for collections that implement IList
The selection is made in one of two ways. The first approach is based on method overloads that exist for the CreateWrapper method. So as long as the compiler can find out what type you’re using, you’ll get the correct wrapper type that way. The second approach uses an overload of the CreateWrapper method that uses “object” as the type of the collection. In this case, an algorithm runs that uses Reflection to find out in which category (of the above list) the given collection fits. This second approach seemed necessary as there are many situations when coding in .NET, where a collection type is obtained from some source that is not clearly typed (like a control’s DataSource property, to name one simple example).
Finally, the parameter “propertyDescriptorCollection” is of course just that – the collection of property descriptors that is returned by the ITypedList method GetItemProperties. There is a property called “PropertyDescriptorCollection” on the wrapped collection type, so you can change the collection after the fact. Most of the methods and constructors also have other overloads – read the source to find out more about them.
So, have fun with the library, I hope it’s useful. Let me know if you find any problems, if you have questions or suggestions for extensions.
some funny example about the use of this proposal??
Comment by Alain — 20/2/2007 @ 12:18 am - 1 year, 7 months ago
Hi Alain -
Not sure I understand your question… you want to know why this idea is useful? Why would you use ITypedList - for all kinds of things - displaying cross tables, ORM, all kinds of magic really. And why wouldn’t you want to derive your own collection classes all the time? Because it’s more flexible to have the ITypedList implementation separately and to have the choice to use it in any one scenario or not. Hm - not sure if that answers your question. If not, feel free to let me know.
Comment by Oliver Sturm — 20/2/2007 @ 12:52 am - 1 year, 7 months ago
Hi Oliver.
for example, how i can customize your solution to aggregate to my collections something like DisplayableProperties (like XPCollection) ??
regards
Comment by Alain — 20/2/2007 @ 9:40 pm - 1 year, 7 months ago
Ah, I see what you mean. Well, that is not something that this library takes care of - it assumes that you have a collection of property descriptors already, that includes just the descriptors you want. The DisplayableProperties property of the XPCollection (that’s from DevExpress’ XPO product, for the uninitiated) influences what actually goes into that collection - so what it does takes place one step earlier.
It’s really simple though. Typically you will have some code similar to this to create your PropertyDescriptorCollection:
// Get the standard descriptors as a starting point PropertyDescriptorCollection origProperties = TypeDescriptor.GetProperties(typeof(MyClass)); // This is the list of properties I want to use in the end List<PropertyDescriptor> properties = new List<PropertyDescriptor>( ); foreach(PropertyDescriptor descriptor in origProperties) { // Based on some logic, decide whether we want to use that original // descriptor or not. if (... my condition ...) properties.Add(descriptor); } // Possibly do further modifications or add custom descriptors to the list ... // Finally, create and return the result return new PropertyDescriptorCollection(properties.ToArray( ));Obviously you could now have something like the XPO DisplayableProperties to influence your decision of which properties are going to be used or not - that would be part of the condition in that loop above.
Comment by Oliver Sturm — 20/2/2007 @ 10:08 pm - 1 year, 7 months ago
Thanks!
Comment by Alain — 21/2/2007 @ 2:15 pm - 1 year, 7 months ago