DataGridView in Windows Forms 2.0
The .NET 1.1 DataGrid had some major limitations. A big one is that it's fundamentally a data bound control. You can bind it to objects, making it useful without a database, but you can't really use it unbound. The DataGridView addresses this quite well. You can directly create row and cell objects, and it even supports a virtual mode. Nice.
A second big limitation of the DataGrid is that it is column oriented. Creating a column where some cells contain checkboxes and others textboxes is difficult, if not impossible. Again, the DataGridView handles this scenario well.
The design-time experience for the DataGridView is where things get a little weird. At design time, the control still appears as if it's strictly column oriented. When you add columns to the grid, you specify a column type - textbox, checkbox, button, combobox, etc. The cells of that column, however, are not restricted to be of that type. You can add a DataGridViewTextBoxCell to a DataGridViewComboBoxColumn, for example, and it works fine.
Perhaps the assumption is that if you are doing fully unbound data display, you won't use the designer to configure your columns anyway. But you still need to add columns in your code, so you basically just pick a random column type. All-in-all, it makes for an odd overall developer experience. Perhaps something like an UnboundDataGridViewColumn or GenericGridViewColumn that can be added in the designer would be helpful (you can already create a generic DataGridViewColumn, but you still need to specify a cell template, so it doesn't really address the problem).
Three other general comments on the control:
- I really wish MS had included hierarchical support. It's an extremely useful UI model at times (MS uses it in their own apps - Outlook being the most prominent example), and that one missing feature will end up forcing me to use a 3rd party control at some point, I'm sure.
- Creating a custom DataGridViewCell type looks at first glance to be more complex than I would like to see. At least, the Reflector'd implementations of the current cell types are quite complex, essentially doing all of the painting themselves. However, I'm not sure yet if that's a requirement or just for best performance.
- I wish there was a way to plug in a custom column type to the design time experience for the control. Once you start using custom column types, you're pretty much outside of the designer.