.net Value Class sorting with IComparable
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 strin开发者_JS百科g 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 implementing IBindingListView
, 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
, calling GetValue
and then using Comparer.Default.Compare(x,y)
. Once you've called GetValue
there 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 PropertyDescriptor
you are getting into very implementation-specific code, that doesn't support the general ComponentModel
view of the world (so it won't work on data-tables or bespoke models, etc).
Unfortunately there's no way around this; at some point, the DataGridView
is going to deal with the value as an object
, meaning that it will have to be boxed if it's a value type.
精彩评论