I’ve observed some weird behavior (likely a defect) when DesktopListBox’s SelectionChanged is called when the Requires Selection option is enabled:
My SelectionChanged event:
Var selectedRow as Integer = serialNumbersListBox.SelectedRowIndex
System.DebugLog("SelectionChanged: row = " + Str(selectedRow))
if (selectedRow = ListBox.NoSelection) Then
myActivationsListBox.RemoveAllRows
else
// do my code for the selection changing (irrelevant to this example)
End If
This works GREAT. UNTIL I click below the last row.
In that case, I get a SelectionChanged where the selected row index is the last row (3). OK, fine.
But what happens next is that DesktopListBox.SelectionChanged is called in a cascade dozens of times!
Here’s some simple message debugging that shows what’s going on:
Here I click on the last row, row 3 (there are four rows):
SelectionChanged: row = 3
That’s perfect. SelectionChanged is called. I click on another row, row 1:
SelectionChanged: row = 1
Same good, expected behavior. NOW, I click BELOW the last row, row 3:
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
SelectionChanged: row = 3
This doesn’t happen when Requires Selection is NOT enabled. In that case, SelectionChanged is called ONCE, with the row passed -1, as expected.
I can (and should) inhibit my own code from doing anything if there’s no change to the selected row, which will prevent the unexpected SelectionChanged cascade from impacting performance (which it would). But this appears to be a unexpected defect.
