Fix Up and Down arrow buttons not disabling at first and last items in Collection Editor

[Rabina4363sf]

Fixes #3152

Proposed changes

• Updated the UpdateEnabled logic in CollectionEditorCollectionForm to correctly handle boundary conditions for item movement.
• Added logic to disable the Up button when SelectedIndex is 0, preventing invalid upward moves.
• Added logiic to disable the Down button when SelectedIndex is equal to Items.Count - 1, preventing invalid downward moves.

Customer Impact

• Fixes incorrect behavior where the Up and Down buttons remain enabled even when no further movement is possible.
• Prevents users from attempting invalid actions when the first or last item is selected in the collection.
• Improves usability and clarity in the Collection Editor by properly reflecting item movement boundaries.
• Ensures consistent behavior across controls like ImageList, ListView, TabControl, TreeView, and MonthCalendar.

Regression?

• No

Risk

• No

Screenshots

Before

After

Test methodology

• Created unit tests to verify the enabled state of the Up and Down buttons for different selection scenarios in the Collection Editor.
• Covered key cases including: first item selected, middle item selected, last item selected, no selection, and single-item collection.
• Validated that the Up button is disabled at the first item and the Down button is disabled at the last item.
• Ensured both buttons are disabled when no item is selected or when only one item exists in the collection.

Accessibility testing

• Verified that the Up and Down buttons correctly reflect their enabled/disabled state based on the selected item position.
• Confirmed that keyboard users cannot trigger invalid actions when the first or last item is selected.
• No regressions observed in keyboard navigation or control interaction within the Collection Editor.

Test environment(s)

• OS: Windows
• SDK: 11.0.100-preview.3.26170.106

Microsoft Reviewers: Open in CodeFlow

[LeafShi1]

Suggestion: This test relies on the SelectedIndexChanged event being wired up to call UpdateEnabled() automatically. In a test environment (where the form is never shown), the event wiring may not be fully initialized, making this test fragile.

Consider calling UpdateEnabled() explicitly after each selection change to make the test deterministic:

listBox.SelectedIndex = 0;
a.UpdateEnabled();  // Don't rely on event — call explicitly
up.Enabled.Should().BeFalse();

This also makes the test more readable — it's clear we're testing the logic of UpdateEnabled(), not the event wiring.

[Rabina4363sf]

Thanks for the suggestion. I’ve updated the test to call UpdateEnabled() explicitly after selection changes to avoid relying on event wiring. Included in the latest commit.

[LeafShi1]

Suggestion: The test implicitly assumes AddItems selects the last added item (index 2). If AddItems behavior changes in the future, this test will fail without a clear reason.

Consider adding an explicit assertion on the initial state:

a.AddItems(new object[] { 1, 2, 3 });

// AddItems selects the last added item by default
listBox.SelectedIndex.Should().Be(2);
up.Enabled.Should().BeTrue();
down.Enabled.Should().BeFalse();

[Rabina4363sf]

I’ve added an explicit assertion for the initial state after AddItems so the behavior is clearly verified. Updated in the latest commit.

[LeafShi1]

Suggestion: After listBox.Items.Clear(), SelectedIndex becomes -1. If UpdateEnabled() is not triggered by the clear operation, the button states here could be stale values from the previous assertions rather than reflecting the current state.

Same recommendation: call a.UpdateEnabled() explicitly after AddItems to ensure we're verifying the actual logic, not leftover state.

[Rabina4363sf]

Agree with this. I’ve added an explicit UpdateEnabled() call after the state changes to ensure we’re validating the correct state. Fixed in the latest commit.

[Rabina4363sf]

@dotnet-policy-service agree company="Syncfusion, Inc."