Today I noticed this blog post by Nigel Spencer discussing his experiences with both Microsoft's WPF datagrid and Xceed's. I liked that Nigel recognizes that any new datagrid coming out this year will be significantly behind in maturity. If you take a look at the 25 releases of Xceed's WPF grid so far, you'll see hundreds of improvements to the product over the 2.5 years it has been on the market. Not only would you have to live through that with any new datagrid coming out soon (or even in the past year), but the competition's pace will be slower. That's because Xceed's UI controls team, which used to make a variety of controls for Windows Forms, is now focused entirely on datagrids and hasn't spread its teams to design ribbons, charts and other WPF controls not directly related to datagrids.

Nigel also mentions the Microsoft WPF toolkit datagrid. Nice to see that he thinks we got a few things right that Microsoft might have missed in their v1. Here's a portion of his post:

So how does the Xceed DataGrid stack up against Microsoft’s? Here are some of the benefits that I’ve found so far:

• Binding to SelectedItem works just fine.
• ReadOnly properties support at Grid, Column and Row level.
• CheckBox column allows simple styling whilst preserving ReadOnly value.
• Automatically supports current selection and edit indicators in the row header.
• The grid theme matches the OS theme out of the box. This is how it should be. Sure the grid can be custom styled to suit but it only makes sense that by default the grid should match the look and feel of the standard themed controls.
• When auto-generating column headers it correctly uses any System.ComponentModel.DisplayName attributes that have been applied to the underlying class.
• There are lots of options at grid and column level that determine how a cell should enter edit mode. This is very useful for columns such as CheckBox columns where requiring a click to enter edit mode can be highly annoying (since the user would expect the click to toggle the checkbox).

Here are a couple of things Nigel suggests we could improve in an upcoming version:

• An easier mechanism for custom sorting. Rather than having to specific custom IComparer implemenations often it is easier to refer to an unbound property that contains the raw data. Like Microsoft’s SortMemberPath property. Hmm… I wonder if you could use a generic SortComparer to provide the same functionality?
  
• Smaller assembly size. I know these days 2.08Mb shouldn’t be an issue but for my current contract it is. We have a ClickOnce application that is deployed to machines in remote country areas. Many of these machines are still using dial-up! Adding another another 2Mb to our current 4.5Mb total is a decision not to be made too lightly. [We’ve already been burned with a ridiculously bloated NHibernate assembly (1.6Mb)]
  

Thanks for the suggestions. You can be sure the team has noticed them.