Would you happen to know an approximate time of this next release?

 

Navigation properties generated by the DevForce EF object Mapper are currently typed as IList<T>, although in fact what you are being returned is a RelatedEntityList<T>, and the returned list can be cast as such. In the future we may change these to return a RelatedEntityList<T> directly. (First we have to solve a problem or two that arises when related entity lists are returned in an anonymous type via a LINQ query.)

 

Whatever type we return when you reference a navigation collection property, it won't (at least by default) implement INotifyCollectionChanged, because that interface is defined in the WindowsBase assembly, which is all about WPF, which is, of course, all about the presentation layer of an application, not the business model. Microsoft has worked hard to keep these layers separate, and so have we. A developer building an application with a DevForce EF persistence layer and a WinForm user interface might well wonder why he needs a reference to an assembly designed for WPF support!

 

On the other hand, it is likely that whatever list we return will provide notification of changes in some form, possibly through implementation of IBindingList<T>.  That seems to provide the same notification functionality that INotifyCollectionChanged does, except that it has the advantage of being recognized by Winforms data binding as well as WPF data binding. See this discussion from Rocky Lhotka:

 

     http://forums.lhotka.net/forums/thread/17402.aspx

 

The best you can do meanwhile might be just to tell the control, when you update the list, to refresh itself. You can find discussions of that by googling "refresh wpf binding". E.g.,

 

 

Pretty sure we'll have a better solution for you in the next release.

 

When we add a new Address to a Customer, we do something like this:

newAddress.Customer = ourCustomer;

ourCustomer.Addresses_Reference.AddEntity(newAddress.EntityAspect.EntityKey);  // probably unnecessary

 

Although the ourCustomer.Addresses collection itself now contains the new address, it does not show up in the ListView. The binding is not triggered as the collection does not seem to be bindable: it does not implement the INotifyCollectionChanged interface required for WPF bindings.

 

Question : how does one go about implementing such bindings without having to repeatedly move elements between  relation collections and externally declared EntityList<T>-s?

While this workaround might work for a relatively small application, an enterprise app. containing hundreds of dialogs would suffer painfully.

 

Thanks for any suggestions...