SortedBindingList exception in 5.4.2, but works in 4.11.2

[michaelcsikos]

I've noticed some different behaviour which has shown up in SortedBindingList but I'm not sure this class is the root cause of the issue.

I have a BusinessBindingListBase wrapped in a SortedBindingList which is bound to a BindingSource. Then add one or more new items to the list, then cancel the edit following the typical pattern. From the attached minimal test sample:

private void Cancel(object sender, EventArgs e)
{
    bindList.RaiseListChangedEvents = false;

    Unbind(false);

    MyChildren.CancelEdit();

    bindList.RaiseListChangedEvents = true;

    BindUI();
}

public void Unbind(bool apply)
{
    IEditableObject current = null;

    if (bindList.DataSource != null && bindList.Position >= 0)
        current = bindList.Current as IEditableObject;

    if (!(bindList.DataSource is BindingSource))
    {
        if (current != null)
            bindList.DataSource = current.GetType();
        else
            bindList.DataSource = null;
    }

    if (current == null)
        return;

    if (apply)
        current.EndEdit();
    else
        current.CancelEdit(); // Index out of range in 5.4.2
}

In version 5.4.2, current.CancelEdit() is crashing in SortedBindingList in the SourceChanged(object sender, ListChangedEventArgs e) method handling the case ListChangedType.ItemDeleted. This method is being called twice with the same arguments, so when it goes to remove from the internal list it's throwing index out of range.

I suppose the question is, why does SourceChanged get called twice in 5.4.2?

The attached sample tests this for both 4.11.2 and 5.4.2. Click Add item one or more times, then click Cancel.

CslaSortedBindingListTest.zip

Are we supposed to be doing something different in 5.4.2? We've been using code like this for a very long time.

Thanks in advance.

[rockfordlhotka]

I suspect a change in .NET itself, as the history for SortedBindingList shows it hasn't changed in at least 6 years. Probably a lot longer would be my guess, as I haven't dealt with Windows Forms for a very long time.

[michaelcsikos]

In the sample I attached the only difference is CSLA. Both sample projects target .NET 4.8.

[rockfordlhotka]

In that case I'm suspecting there's some change in the n-level undo code somewhere. I know there was some work in here to collapse the Silverlight and .NET variations of some code implementations into what is now a unified codebase, and perhaps that introduced a bug. Just guessing though.

Can you please file this as an issue in the Issues tab?