Making selectedIndex -1 on a databound dropdown

[23s]

I have a dropdown bound to a dataview. The binding assigns the dropdown
with a SelectedIndex of 0.

There is a msgbox in the SelectedIndexChanged event that displays the
SelectedIndex property.

There is a button that programatically sets the .SelectedIndex property of
the dropdownlist to -1.

I am consistantly observing the following 2 behaviors when pushing the
button, dependant upon the SelectedIndex value of the dropdown prior to
pushing the button.

If the dropdown SelectedIndex = 0, pushing the button displays "-1" and the
dropdown's selection is cleared. This is the behavior I expected.

If the dropdown SelectedIndex > 0, pushing the button displays a message
"-1" and the dropdown's selection is cleared. However, immediately
thereafter, "0" is displayed, indicating the SelectedIndexChanged event has
fired again, and indeed the dropdown now displays the first item. This
behavior is unexpected.

I cannot find any code that would explain this behavior in my program. Is
this a known behavior of the dropdown control, or am I going crazy?

 

[Herfried K. Wagner [MVP]]

If the dropdown SelectedIndex > 0, pushing the button displays a message
"-1" and the dropdown's selection is cleared. However, immediately
thereafter, "0" is displayed, indicating the SelectedIndexChanged event
has fired again, and indeed the dropdown now displays the first item.
This behavior is unexpected.

I cannot find any code that would explain this behavior in my program. Is
this a known behavior of the dropdown control, or am I going crazy?

BUG: ComboBox Does Not Clear When You Set SelectedIndex to -1
<URL:http://support.microsoft.com/?scid=kb;EN-US;327244>

Maybe this bug was fixed in .NET 1.1 SP1.

 

[23s]

Interesting, thank you for the link. The suggested work around is to set
the SelectedIndex to 0 before setting -1, which I had considered doing after
observing the behavior, but did not want to add "fixes" such as this to
compensate for my own error elsewhere in the program. At least now I can
justify implementing the fix knowing it is not my own error

I am using .NET 1.1 SP1, so unfortunately this bug still exists in this
version.