- implement INotifyPropertyChanged in the business object.
- before the ItemsSource is set, loop thru all the items and tag the PropertyChanged event,

northwind.Orders.ForEach(o=>{
o.PropertyChanged += (s,e)=>{
var changedItem = s as Order;
orders[orders.IndexOf(changedItem)] = changedItem;
};
});

- Above code is not very well written, but that should be it. The CollectionView has a INotifyCollectionChanged interface implemented, this will trigger with “e.Action == NotifyChangedAction.Replace” event, if the control listens to this action and refreshes the UI internally, then this should work well.

Check it out!!!

If a view is sorted on “DOB”, and a PropertyChanged event notifies you that an item’s “DOB” property was modified, it stands to reason that the view should be re-sorted. Same for grouping and filtering.

It would be easier to get this done if C# had first-class support for weak events. The current “WeakEventManager” approach is a lot of code and static class overhead every time you just want to implement the Observer pattern. Any clue if this is ever going to happen, Doc?

Fair enough. I have been struggling this problem for quite a while now; I was hoping this would finally provide a solution that wouldn’t require enormous amounts of custom code. But it looks like I am going to have to go back to writing my own filter/sort collection, essentially re-creating all of the functionality in ListCollectionView, because the framework version is missing one very small extensibility point.

It’s just very strange to me that this problem wasn’t addressed in the first round of WPF design, much less the second or the third. It seems to me to be an extremely common scenario: change an item and have that item updated accordingly, wherever it may be. Isn’t that the whole point of databinding in the first place? Although I suppose that everyone thinks that their own problems are common scenarios…

What I describe in this article is merely a hack that leverages this new feature to allow the refreshing of a single item. Prior to IEditableCollectionView, this was not even possible.

I agree that it would be nice to see a method that allows a single item to be manually refreshed within a collection view. I’ve requested this before and I know others have too. There are definitely changes coming for WPF 4.0 in this area, but I don’t know if this particular feature was added. I’ll take a look when I have some bandwidth and post back here.

Objects are being update asynchronously inside the model. The model does not necessarily know all of the collections of which the object may be a member, since those collections only exist in the presentation. So there is no way for EditItem to be called in advance of the edit.

Combine that with Justin’s point about items that are not yet a part of the collection, and it really seems like the WPF team took the completely wrong approach to solving this problem. IEditableCollectionView and the corresponding implementations in CollectionView and ItemCollection only address certain very narrow use cases. It seems like providing a Refresh(item) method (that works for any item from the underlying collection) would have been a much simpler and much more broadly applicable solution.

Yes, Justin, that is a drawback to leveraging IEditableCollectionView to cause an item to be updated in the view…. namely, the item must already belong to the view. I *totally* feel your pain here. I have the same scenario in an app and the only option is to refresh the entire view (or remove/readd the item, as you suggest).

The framework developers probably did not anticipate folks using EditItem/CommitItem to update a view like this. I am going to request that they add a specific method to ICollectionView for updating a single item in the view.

Cheers,
-dw