In the current agile sprint for the dev team I manage, we decided to start replacing ListViews (custom ones at that) and grids with the XtraGrid from DevExpress.
Now, normally I shy away from 3rd party controls, or want to vet them, but I knew there was no way we could do the same functionality in the default grid in .NET. One of the guys on the team did a story the sprint before to do a proof of concept comparing various grids and showing the pros and cons. DevExpress came out ahead, functionality and performance.
What we are seeing now is huge gains. We can use the new grid and functionality we couldn’t even begin to think of, is there by default. Grouping, searching, filtering, FAST performance, print preview and formatting, etc, etc, etc. Tons of options.
In fact, there are TOO many options. It makes it hard for us to digest all the possibilities in what we want to turn off, or how to integrate with existing forms, etc. A good problem to have.
All I know, is if you are doing any serious .NET work (Winforms, WPF, even Web/Silverlight) – it might make some sense to take a look at DevExpress. Focus on your business rules and integrating other parts of your systems, not reinventing the wheel with a crazy custom grid.
In the coming months I will try to talk about other areas that you can “outsource” to 3rd parties, where it makes sense. (And no, I don’t get anything from DevExpress for this post. Just calling it how I see it).
Steve Novoselac's Blog 
2 replies on “Winforms DevExpress Grid”
[…] custom control that you’ve had in your app that you can replace with built in functionality or a better architected 3rd party control. Users will get the added functionality (enhancement), crazy bugs from your custom code are gone […]
LikeLike
This grid is to be avoided. It simply isn’t up with industry standards. In fact, this last statement could be applied to DevExpress as a whole. Can you believe that this company actually believes swallowing exceptions thrown from within event handlers helps ensuring application stability? Any developer even the least bit competent understands that this is plain and simply wrong!
If, for example, you want to use the RowUpdated event to implement an autosave routine, you must take extra precautions to make sure potential exceptions gets reported. Otherwise you may end up suffering data loss and corruption.
As of today they still don’t see this as a problem. IMHO this just tells that they can’t be trusted with quality.
LikeLike