Thanks Ambrose! Don't s'pose you could influence 'em to fix their "printable" view? It "prints" at a fixed column width of something like 500 pixels...

Anyways, appreciate the code sample and article - very informative!

I'll let them know it is a problem. Thank you.

Thanks for the code, Ambrose. I am currently designing the business components for our company, and I wasn't looking forward to creating a separate IComparer class for every field in every collection class that I have. I'm looking forward to testing your solution in our current environment.

No problem, Scott. Please let me know if you find any problems or have any suggestions to improve it.

Hi !

I have read your article in the Code Magazine, then finnaly found the VB.NET code for the "SortableCollection" class. However, where is the "Add()" method of that collection ? I have created a "MyCustomCollection" that inherits your SortableCollection class, but I get the "GetNewView() method, I got the "Sort", but no Add(). Am I missing something ?

Right, so you will be inheriting from the SortableCollectionBase, and you will want to implement your own Add, Remove, and indexers because you want to have strongly-typed versions of these methods. You'd do this if you inherited from CollectionBase itself, FWIW. :)

Hello,

I have a few issues with the provided solution.

Type safety is circumvented by allowing property names to be encoded as strings. Using symbol-based refactoring tools to rename fields will undoubtedly cause code using these sort expressions to break at runtime. The decision to circumvent the type system should never be made lightly, as application integrity is at stake. Also, don't you think that code generation is overkill for something as simple as a sort operation?

In .Net 2.0, it is quite easy to generate anonymous delegates that implement everything above in a type-safe manner. Your 2.0 implementation could stand to be a great deal simpler using these features, right?

As software developers we need to constantly evaluate the tradeoffs of each solution. Code generation is, in my opinion, one class of solution that should be implemented only when existing language abstractions and features have been exhausted, simply because I believe the complexity of the solution should be commensurate with the complexity of the problem being solved.

Thanks for the comments. This was published a year ago, and the solution was developed months before that. As such, 2.0 features were not really core to the solution. The stuff that the LINQ teams are doing is certainly better than this solution, and if you can go that route, yeah, do it.