ListBox.Items.RemoveAt causing selectedItemChanged to fire

[mjneedles]

I have a form with a ListBox and two ComboBoxes. Selecting an item in the Listbox triggers code to populate the first combobox, and selecting an item from the first combo populates the second combo. Then the code processes the selected item from ComboBox2 and removes the selected item. Each item in ComboBox2 is processed and removed, then the selected item in ComboBox1 is removed, and the user has to select another. This process is repeated until all the items in ComboBox1 are removed, then the code removes the selected item in ListBox.

In all cases, the removal is done with RemoveAt().

My observation: Removing an item from a ComboBox does not cause the selectedItemCha nged event to fire, but it does for the ListBox. Why? Can I cause this to not happen?

Thanks for your help,
Matt Needles

[tlhintoq]

Does it *always* fire the SelectedChanged event?
Or only if you remove the selected item, forcing a new item to become selected?

[mjneedles]

As specified, it fires when I remove the selected item. However, this does not happen when I remove the selected item in a ComboBox. Why?

[tlhintoq]

If you delete the selected item of a combbox, then a new item has to become selected. Its the nature of a combobox. Even if it is item index -1 meaning no item selected.

If you delete the selection of a listbox you can be left with an empty text area, yet no selection has been made/changed. Thus no event.

[mjneedles]

If you delete the selected item of a combbox, then a new item has to become selected. Its the nature of a combobox. Even if it is item index -1 meaning no item selected.

If you delete the selection of a listbox you can be left with an empty text area, yet no selection has been made/changed. Thus no event.

This doesn't answer my question: Why does removal of an item from a ComboBox NOT cause a selectedItemCha nged, when it DOES for a ListBox? I need to remove an item from a ListBox and NOT get the event. How?

[mjneedles]

If you delete the selected item of a combbox, then a new item has to become selected. Its the nature of a combobox. Even if it is item index -1 meaning no item selected.

If you delete the selection of a listbox you can be left with an empty text area, yet no selection has been made/changed. Thus no event.

I think you got these backwards. ListBox has no textarea, it's comboboxes that do.

[Christian Binder]

You could simply suppress the handling of SelectedItemCha nged-Event.
That's the way, I handle these problems (and it works very well as long as there are no asynchronous operations).

bool suppressItemChangeEvent = false;

void fu() {
  suppressItemChangeEvent = true;
  listBox1.RemoveAt(0);
  suppressItemChangeEvent = false;
}

void listBox1_SelectedItemChanged(...) {
  if(suppressItemChangeEvent)
    return;

  //... your code for handling the chg-event
}

[tlhintoq]

This doesn't answer my question: Why does removal of an item from a ComboBox NOT cause a selectedItemCha nged, when it DOES for a ListBox? I need to remove an item from a ListBox and NOT get the event. How?

I know this is going to sound like your parent saying "because", but it's the truth...

Why is a NumericUpDown.V alue a decimal type while a TrackBar.Value is an int type? Because that's the way Microsoft built their framework. It's the kind of inconsisency that happens when 10,000 people work on a single project. One guy thinks something should work one way so that's what he does in the 10 controls he builds. Someone else interprets the instructions differently so his 10 controls work a little different. Or there is some reason why it was done that way that makes sense under a certain condition, but that condition doesn't apply to your situation so it doesn't make sense.

When I first started learning C++ I couldn't make any progress. I kept getting upset about all these inconsistencies . I would bitch and moan and yell at the air: "WTF are these guys thinking?" ... "Why on Earth would you do xxx instead of zzz?" ... "This makes no sense!"

Then one day a new mind-set hit me. Quit fighting it. It doesn't matter *why* because I can't change it. Knowing the *why* won't change the behavior. I just needed to be able to recognize and quantify the behavior and code around it. Once I came to grips with the fact that knowing the *why* did nothing to benefit me I was a lot happier and my blood pressure a lot lower.

[mjneedles]

You could simply suppress the handling of SelectedItemCha nged-Event.
That's the way, I handle these problems (and it works very well as long as there are no asynchronous operations).

bool suppressItemChangeEvent = false;

void fu() {
  suppressItemChangeEvent = true;
  listBox1.RemoveAt(0);
  suppressItemChangeEvent = false;
}

void listBox1_SelectedItemChanged(...) {
  if(suppressItemChangeEvent)
    return;

  //... your code for handling the chg-event
}

Thank you, ChBinder. Your solution will serve me well. I agree with the philosophical response of tlhintoq, but I didn't just ask Why, I asked if there was a way to avoid that happening. Your response helps resolve my problem.