Issue with SortedBindingList's handling of ListChangedType.ItemChanged

Brian Criswell posted on Wednesday, June 07, 2006

I think something was missed with the implementation of SortedBindingList.SourceChanged, near line 724.  All that is done is that the SortedBindingList reraises the event with the sorted index instead of the source's unsorted index.  However, if the sorted property is what changed on the item in the source list, that item is no longer in the correct position in the sorted list.  I think the sorted list should be resorted on ListChangedType.ItemChanged if the sort property of the changed item no longer fits between the sort property of the items that come before and after it in the sort list.  This would bring the behaviour more in line with the handling of ListChangedType.ItemChanged where the added item is inserted into the correct location in the sorted list.

RockfordLhotka replied on Wednesday, June 07, 2006

Are you looking in the ItemAdded or ItemChanged section? The line numbers are different in VB and C# so I don't know where you are looking for sure. I assume you are looking at ItemChanged?

Most importantly, do you have a concrete example of where it acts incorrectly (raises the event for the wrong item or something)?

It is intentional that the list doesn't re-sort when you edit the sort column value, as the result in the UI is quite jarring - the row disappears out from under the user and data binding gets quite confused about what's being edited (currency). I'd originally tried it this way, but it isn't workable due to the unpredicable results in the UI.

Brian Criswell replied on Wednesday, June 07, 2006

Sorry, for not being more clear.  It is in the ItemChanged section of the C# code.  I did not realize that it was intentional.  I will just keep catching the ListChanged event filtering for ItemChanged and reapplying the sort in my UI code.

Cheers.