If you look at my ObservableCollections project, you will see that I am intimately familiar with IUserCollectionType. And I will continue using that API even with the changes I am suggesting. As I wrote in my above post, however, the problem now is that the breaking changes in NH 2.1 are making it impossible to intercept all modification operations on persistent collections. NH 2.1 targets .NET 3.5, and observability is a fundamental feature of .NET 3.x, so I think the best way to solve this problem is to incorporate observability into the NH core.
On Nov 26, 7:12 pm, "Fabio Maulo" <[EMAIL PROTECTED]> wrote: > The public API is IUserCollectionType > > > 2008/11/26 HappyNomad <[EMAIL PROTECTED]> > > Observable collections are an integral part of .NET 3.x and WPF in > > particular. Last year I added support for observable collections by > > using NH's custom collections API, and made the solution available > > here: > > >http://happynomad121.blogspot.com/2007/12/collections-for-wpf-and-nhi... > > All that work took me a month, but it was worth it since it's been > > helping a lot of people use WPF together with NH. > > > When I tried compiling my ObservableCollections project against the > > trunk just now, however, I got some unsettling compiler warnings/ > > errors. Looking at the source code for PersistentGenericList, etc. I > > can see the breaking changes made since NH v2.0.1.GA. That is, > > all .NET collection interface members were made to be explicitly > > implemented. The problem with that, is that I cannot override them > > then call their original implementations from my > > PersistentObservableList, etc. subclasses. > > > Afaik, this problem must be solved within the NH sources. What I > > would like to do, is add this template method to > > AbstractPersistentCollection: > > protected abstract void OnCollectionChanged > > ( NotifyCollectionChangedAction action, object changedItem, int > > index ); > > and then call it from all of its subclasses, whenever the collection's > > contents are modified. Just look at my ObservableCollections project > > to see how this method's parameters are determined for each collection > > and modification type. > > > We could even take this one step further by implementing > > INotifyCollectionChanged on AbstractPersistentCollection. That > > interface contains just one member: CollectionChanged. In that case, > > I could also provide an implementation for OnCollectionChanged. > > > I can undertake this task myself, if I've been assured that the patch > > I create will be committed once I've finished. > > -- > Fabio Maulo
