8768 :: Resolve Addrange issue after sorting.

[Epica3055]

Fixes #8768

Proposed changes

if tree is already sorted then we don't want to set fixed Index value. due to these reason It is misbehave.

Customer Impact

• No

Regression?

• Yes

Risk

• No

Before

When the user adds a value to the treenode list and sorts it using treeview.sort(), it works fine. Subsequently, when the user adds individual trees through the add event, it functions as expected and sorts the entire tree automatically. However, if the user adds multiple values through AddRange, it does not work as expected.

After

I've fixed the sorting issue we discussed earlier, and now everything is working smoothly. When users add values individually or use treeview.sort(), the sorting works fine. Even when they add multiple values at once using AddRange, the sorting behaves as expected.

Test methodology

• Testcase added

Test environment(s)

• tested with .net core 8.0

Microsoft Reviewers: Open in CodeFlow

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.39955%. Comparing base (f53f153) to head (56b8866).
Report is 72 commits behind head on main.

Additional details and impacted files

@@                 Coverage Diff                 @@
##                main      #11423         +/-   ##
===================================================
+ Coverage   74.29395%   74.39955%   +0.10560%     
===================================================
  Files           3026        3032          +6     
  Lines         627152      628196       +1044     
  Branches       46758       46813         +55     
===================================================
+ Hits          465936      467375       +1439     
+ Misses        157863      157468        -395     
  Partials        3353        3353                 

Flag	Coverage Δ
Debug	74.39955% <100.00000%> (+0.10560%)	⬆️
integration	17.98384% <0.00000%> (-0.00630%)	⬇️
production	47.23616% <100.00000%> (+0.20588%)	⬆️
test	96.96755% <100.00000%> (-0.02013%)	⬇️
unit	44.21834% <100.00000%> (+0.20676%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[Tanya-Solyanik]

Hi @RutulPatel8 - I apologize that we had accidentally destroyed your branch when reviewing and trying to rebase it on the latest. This PR restores your changes with minor modifications, see the commit history, we applied the fix to the failing test, used fluent assertions in the new test and used [WinFormsTheory] instead of the [WinFormFact] on the test. You can continue working in this branch by pulling it down using GH Client gh pr checkout 11423, GitHub Desktop, or VS-Code. Or you can cherry-pick your commit c6dd018 and create a new PR.

Because this change could be breaking for someone who is not sorting nodes intentionally, it requires an opt-out switch. If you are not planning to pick it up, a team member can add this switch and finish this work. Please let us know if you have the bandwidth to wrap it up in 2 weeks. This will give us time to get this change into the next preview.

[Tanya-Solyanik]

Please use TreeNodeCollectionAddRangeRespectsSortOrder as a switch name, and make it an opt-out switch, i.e. default value should be true.

[Tanya-Solyanik]

Added a minor comment, otherwise looks good

[Tanya-Solyanik]

Suggestion:

When set to (default), API will insert nodes in the sorted order. To get behavior compatible with the previous versions of .NET and .NET Frameworek, set this switch to .

[RutulPatel8]

Hi @RutulPatel8 - I apologize that we had accidentally destroyed your branch when reviewing and trying to rebase it on the latest. This PR restores your changes with minor modifications, see the commit history, we applied the fix to the failing test, used fluent assertions in the new test and used [WinFormsTheory] instead of the [WinFormFact] on the test. You can continue working in this branch by pulling it down using GH Client gh pr checkout 11423, GitHub Desktop, or VS-Code. Or you can cherry-pick your commit c6dd018 and create a new PR.

Because this change could be breaking for someone who is not sorting nodes intentionally, it requires an opt-out switch. If you are not planning to pick it up, a team member can add this switch and finish this work. Please let us know if you have the bandwidth to wrap it up in 2 weeks. This will give us time to get this change into the next preview.

Hi @Tanya-Solyanik ,
Are you still working on these issues?
If yes then I can help you.

Let me know so I can generate PR with all existing and remaining changes.

[Tanya-Solyanik]

@RutulPatel8 - thank you! We are done with the new appcontext switch and tests. This fix will ship in the next preview, assuming everything goes well, please test it on your side. But we have many other issues we are looking for help with.