I’m running into an issue using a DataGridView bound to a iBindingListView implementation (third party dll) attached to a large collection.
There’s a certain property in my collection type, named MyDateTime, which is a value class similar to DateTime, but also with some legacy code.
This struct implements iComparable, iComparable<T>, and iEquatable<T>.
The issue I’m having is this:
When I apply a sort to the iBindingListView on the MyDateTimeColumn, it ALWAYS uses the non-generic iComparer, causing hundreds of thousands of unnecessary boxing and unboxing.
When I use the Automatic Sorting provided by the DGV, it does a string sort on the column. Keeping this column “automatic” instead of programmatic for just this column would not be acceptable.
When I remove the non-generic iComparer, the generic one is still not used, it just does a string compare on the .ToString().
Am I missing something? Why is my generic comparer not bieng called on a sort?
Ultimately this type of data-binding is often reflection-based, and reflection is
object-based; so boxing is a reality. Actually, you can control this when implementingIBindingListView, but it would be a large amount of work, and I’m guessing they simply haven’t (sensibly).The simpler way to do this (which I’m assuming they are using) is to trust the
PropertyDescriptor, callingGetValueand then usingComparer.Default.Compare(x,y). Once you’ve calledGetValuethere isn’t any point not using the object you’ve already boxed (and would have to then unbox).And if you don’t trust the
PropertyDescriptoryou are getting into very implementation-specific code, that doesn’t support the generalComponentModelview of the world (so it won’t work on data-tables or bespoke models, etc).