We are aware that MS is planning to release a DataGrid control in a service release later this year and yes they are making some changes in the framework that will benefit them when implementing their DataGrid - e.g. container recycling, deferred scrolling - both of which we have already implemented within our framework.

With regard to Rockford's comments, I actually had a different take on it. Just because INotifyCollectionChanged and IBindingList provide a means for notifying a listener that the contents have changed does not, at least in my opinion, mean that INotifyCollectionChanged supercedes IBindingList. For IBindingList, the notification isn't even a required part of the contract - it exposes a property SupportsChangeNotification that indicates whether it will send a change notification when the contents change and then it could also send a change notification when an item within the collection has changed. IBindingList has 16 members defined on that interface itself - this doesn't even include the 10 members on the base IList interface from which it derives. This would be quite a burden to impose on implementors who simply wanted to provide notifications to the binding infrastructure that items were added/removed. IBindingList is really meant to be implemented by publicly modifiable list classes (or at least potentially modifiable) whereas INotifyCollectionChanged can be implemented by any collection type and is not related/tied to manipulation, sorting, filtering, etc. of that data.

The IEditableObject interface is a generic interface in the System assembly for notifying an object to start/end an edit session for the "row" so I would expect that they would support this interface within their DataGrid - we do within ours. The IDataErrorInfo interface is another common previously existing interface that MS supports within WPF. I know Rockford is probably just using INotifyCollectionChanged vs IBindingList as an example that they could add different interfaces and I think that if MS finds that they need different interfaces that they would implement new ones but in all likelihood they will make use of the existing ones where applicable. It is to their benefit, e.g. to have less to document, and the benefit of their customers, who may already have implement these interfaces on their subobjects, to do so.

Thanks for the response, Josh. I've been following your WPF blog postings for some time.

Your response makes me wonder, however, if you are aware that Microsoft has in fact announced some details on their WPF data grid control coming this summer. They have made numerous infrastructure changes in relation to this and those changes would impact folks like you who build WPF grids. If you haven't yet, please watch Rob Releyea's presentation from MIX08.

Thanks,

Douglas

Douglas,

I do not see things in the same way as Rocky, in this regard.  His assumption that third party control vendors, such as Infragistics, are in the business of emulating Microsoft's controls is what I disagree with. It does not seem too far fetched, in my mind, that the situation is the exact opposite of what Rocky claims.  Microsoft might be waiting to see how others create complex data grid controls, how they structure the APIs, how they provide points of extensibility for developers, etc.  Not the other way around.

Obviously, this is all speculation on my behalf, so I might be totally off the mark.

Thanks,

Josh

Seems Rockford may have been on to something. I'm sure you guys attended Rob Relyea's presentation at MIX? (I ran into Xceed and Telerik; looked for y'all...).  Andrew's post didn't really scratch the itch. How about another shot at it? Is Josh Smith allowed to contribute? I'd enjoy hearing his reaction.

Douglas
CCI