TreeNodeCollection.AddRange works incorrectly for non-empty collection of the sorted TreeView

[snnz]

.NET version

6.0

Did it work in .NET Framework?

No

Did it work in any of the earlier releases of .NET Core or .NET 5+?

No

Issue description

When the tree nodes are appended to the non-empty TreeNodeCollection owned by the sorted TreeView with already created underlying window, the resulting order of items in the actual window does not match the one in the collection (which is correct).

The cause is how method TreeNode.PrevNode works: when called from within TreeNodeCollection.AddRange of non-empty collection, it always uses fixed index as the position of the previous node, assuming the normal backward insertion of the nodes in the unsorted tree. Yet in case of the sorted TreeView, insertions are made at various positions according to a sort order.

There obviously should be a check for the sorted state of the tree in TreeNode.PrevNode to avoid this.

Steps to reproduce

namespace TreeViewTest
{
  internal static class Program
  {
    [STAThread]
    static void Main()
    {
      ApplicationConfiguration.Initialize();

      var treeView = new TreeView();
      treeView.Nodes.Add(new TreeNode("2"));
      treeView.Sort();

      var form = new Form();
      form.Controls.Add(treeView);
      form.Load += (sender, e) => treeView.Nodes.AddRange(new TreeNode[] {
        new TreeNode("3"),
        new TreeNode("5"),
        new TreeNode("1"),
        new TreeNode("4")
      });
      Application.Run(form);
    }
  }
}

This results in:

[merriemcgaw]

Thanks for filing this issue. I will hand this over to the community if someone has ideas for how to fix this and put it under a configuration switch. Given that this has been the behvavior since .NET Framework days, the team will not be able to prioritize it on our end.

[ghost]

This issue is now marked as "help wanted", and we’re looking for a community volunteer to work on this issue. If we receive no interest in 180 days, we will close the issue. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[snnz]

I've submitted a possible fix as PR #8774; it is very simple.

[elachlan]

See #8556 for examples of context switches.

[RutulPatel8]

@lonitra Here is my PR. Can you please review it.

https://github.com/dotnet/winforms/pull/11300

Proof of testing

[RutulPatel8]

@Tanya-Solyanik Can you please review my PR. I can see the issue in XUnit Test but It is not related to the my code.

[Tanya-Solyanik]

@RutulPatel8 - is this issue fixed by PR #11253?

[RutulPatel8]

I'm not sure, but I can say one thing: There have been lots of changes made with these PRs, and I've made the same change by altering a single 'if' condition. Could you please review my PR?"

[Tanya-Solyanik]

I had verified again, this is reproing in .NET Framework, my experiment was wrong because I re-sorted the TreeView after adding the unsorted range

[RutulPatel8]

@Tanya-Solyanik It means still you have facing the same issue and my changes wasn't working with.net framework?

[Tanya-Solyanik]

@RutulPatel8 - your change is good, except for the failing tests. All failing tests are related to treeviews and that they are not failing for other PRs.

[Tanya-Solyanik]

Moving to triage to confirm that we don't want an opt-in switch for this change.

[merriemcgaw]

This has been present since .NET Framework so we will need an opt-out switch for this behavior. @Tanya-Solyanik suggests TreeNodeCollectionAddRangeRespectsSortOrder

This will potentially be a breaking change, but the current behavior is not what we'd expected.

[merriemcgaw]

@RutulPatel8, are you planning on picking this one up, or should we have a team member wrap up the work? Thanks!

[Liv-Goh]

Verified this issue on 9.0.100-preview.6.24312.9 with dlls built from winforms repo of main branch, it was fixed: the tree nodes added by using TreeNodeCollection.AddRange are sorted correctly

[Philip-Wang01]

Verified the issue with .NET 9.0.100-preivew.6.24325.8 TP build. the issue has been fixed that have the same results as above.