I know that ObjectListView is old technology. I am working on a project that is pinned to .NET 2.0 and using CSLA 3.0.5. I'm hoping somebody who used to use this class is still on the forum and has a memory of this technology from 4 and 5 years ago.
The project needs to add filtering to an editable DataGridView. I have updated the UI to bind to an ObjectListView instead of the CSLA-based list. However, that change broke a particular behavior that worked with the CSLA-based list.
The UI observes the ListChanged event of the binding source. It looks for ItemChanged sub-events involving certain properties. When it sees these, it updates UI elements that are dependent on those properties. With the change to ObjectListView, the ItemChanged events are no longer firing when the user edits the values in the grid.
I discovered that the ObjectListView.cs class is intentionally suppressing the handling of the ItemChanged event of the wrapped collection when the ObjectView is in editing mode. If I comment out that condition, then my side-effects are working. I also get the added benefit that when the user edits a value that is part of the filter, the item automatically is cleared from the view if the new value makes the filter condition false.
So, this seems to be working for me, but I'm wondering why it was set this way? Is it possible that it was just a reaction to one of the many quirky behaviors of the DataGridView? Does somebody know why, and am I only opening a Pandora's box with this change?
- Don Benson -
Have you considered to use SortedBindingList and FilteredBindingList?
These are still available in CSLA 4.2 and the 2 classes have received a number of bugfixes.
You should be able to just copy these files into your version of CSLA (or another business assembly).
Copyright (c) Marimer LLC