Question

OK, so I need to create an ICollectionView from an existing ICollectionView. The idea is that I can take whatever filters/grouping/sorting has been set on the existing view and then create other views from that "base" view, in effect "layering" or aggregating my filters, etc.

I need the end view to update its items "auto-magically" when the source collection (an ObservableCollection<T> ) updates and when the data item is updated--like calling the Refresh() method. I need to avoid calling Refresh on all the views because we don t know all the views between the original collection and the end view, and the Refresh() is painfully slow.

We are trying to avoid rolling our own view classes--we would prefer (strongly) to use something that already exists in the .net library.

Update

We have a call in to Microsoft about this. I know others have the same problem, as least, that what Dr. WPF tells me.

Answer 1

OK, so we ended up rolling our own collection and view.

Our collection is based from ObservableCollection which attaches to the PropertyChanged event of every element that is in the collection. We have an event that we invoke whenever the property changes, this way other classes and/or views can hook that and handle it as they see fit.

We then created our own ICollectionView based from ListCollectionView. The view watches for the CollectionItemChanged event from the collection and simply calls (if the item in collection is IEditableObject) IEditableList.EditItem(...) and IEditableList.CommitItem(...)

this Edit() and then CommitItem() causes the view to refresh without actually calling Refresh()

This is totally "haxor" but, it works until the day MS does something for us poor developers to fix this.

友情链接