Steve wrote:
Dave, thanks for info.
I have to disagree on the 'unavoidable' aspect. If you look at how the grid behaves when it's bound to a .NET DataView, it does not reset its view, and it does continue to reapply sorting.
I've to dig with reflector into the DataView class, but I'm pretty sure they also issue a IBindingList.ListChanged event sending a Reset (like we do too). The only thing which might be different is that they likely don't re-sort when you change a value, or only after you move away from the complete row. We do that per field.
How does LLBLGen handle EntityView resorting? Behind the scenes, is a 'new' collection (composed of the original entities) created, with entities added in the requested order? If this were the case, it could explain why the grid resets when it's bound to an EntityView and the sort is reapplied, because the grid thinks it's essentially being handed a new collection.
It maintains an index list of the entities in the sorted order. The enumerator then uses the index list to index into the real collection to return the entities in the sorted order (and also filtered, so only entities which are in the view have their index in the index list). This allows multiple views on the same collection with different filters/sorters.
When an entity changes, the order can be different. So it re-applies the sorter/filter. It then simply raises IBindingList.ListChanged with the 'Reset' parameter, so the bound control has to rebind the data. Otherwise it would have to raise a lot of 'ItemMoved' ListChanged events, after everything was sorted.
The main problem is: how does the bound control identify rows bound to it? most controls have an extra code path for datatables/views and likely peek into the pkfields set of the bound datatable to identify rows (so a reset won't select a different row). In case of bound objects/entities it might not do that and simply select the top row for the active row/selected row. But that's out of our hands.
In the designer we had the same problem with the devexpress grids and a BindingList<some object> so not our entity views: when a value changed, the rows would get re-sorted, but we wanted to keep the same active row visible. We had to re-state what the active row was after a change.
Sorting has to take place at some point when data changes, this is unavoidable (I hope you agree with that ) The main issue then is: when to do this? And after sorting takes place, what is the desired result? I think that last question is the main one: what do you want after changing a cell to happen with the row you're editing? Should that still be the active row or not? The row you edited could be moved (due to the sorting) to a place in the list far below or far above the list of rows currently viewed by the grid. Do you want to keep viewing those rows, or do you want to move up/down to the row you were editing?
I don't know in what kind of behavior a datatable bound to a datagridview results in with these questions, but it seems to me you have either tell the datagridview how to identify the rows or do the manual selection after sorting/changing.