How to not get combobox SelectedIndexChanged be executed on load

Question

Hello,
As what the subject line is.... What is the method to not allow combobox SelectedIndexChanged to be executed on load... and only make it to be executed when a "USER" changes the selection value.

Thanks

Answer 1

Try using a boolean flag to indicate the'load' event, and check it in the selectionindexchanged event (exiting the event if the load is still in progress).

Answer 2

well it shouldnt change at all if nothing is making it change - perhaps you have some code invoking it to change the index selection of the combobox

Answer 3

I do have it set to something else onload, but the selectedindexchanged loads it back to index 0.

but I might go ahead and do the bool thing, I doubt that will work because it will be a loop.

Answer 4

doing the bool thing could be a temp solution but not best practice.

What is this thing you are doing onload? perhaps you can do this process at some other point? If you can explain more in depth on what your code is doing onload, perhaps I/we can give you a better solution - if you would like :-)

 

Answer 5

Why is the boolean flag not the best practice?

There isn't a way that I know of to prevent the SelectionIndexChanged if you change the index at load time.

Answer 6

well anything can go wrong during that but should be kept as an absolute last resort :-) I am sure there is a better way of finding out why the developer (original poster) needs to alter the selected index at start up of the application (onload)

 

I could post some examples but best not until we find out whats happening during onload, with some code :)

Answer 7

I don't see that changing the index of a combo box at load time is at all unusual: unless you know of a better event to set a forms 'properties'

(For example, loading some settings into the form).

What I think is odd, though, is that it gets set back to zero: but this may be precisely the problem. Events are cascading during the form load. In which case the cascading effect needs short-circuiting; by putting a flag at the form level.

I can imagine the following in the form load event:

ComboBox1.SelectedIndex = 1

This will fire the SelectedIndexChanged event on the combobox. By having a 'loading' flag:

Private m_LoadingFlag as Boolean = True

at the form Class Level, you can look for this value in the comboBox SelectionIndexChanged event, before performing any processing:

if m_LoadingFlag then Return

At the end of the FormLoad event, the flag is set false.

Answer 8

Well yes that is true, but I am still trying to figure out why initially the index is being changed.

If its done by the developer, then perhaps we can move that code to some other event rather than onload (so it doesnt change the index until some perhaps user action has happened).

I think i'm getting a bit carried away, my pesonal preference is just interferring! :-) I just do things a bit differently myself, but yes you are right and I would perhaps do that. Although would be nice to see the onload code and see whats happening ;-)

 

Answer 9

Well, this is what is going on.

--OnLoad.. I am  populating the comboboxes and setting the selected value to the value of "Term" variable..... ex:
    [code]
    With Me.cboTerm
            .DataSource = Me.MiscDataTableTableAdapter.GetDataByTerm
            .DisplayMember = "term"
            .ValueMember = "term"
            .SelectedValue = Term
        End With
      [/code]

    and then I have the following:

[code]
Private Sub cboTerm_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cboTerm.SelectedIndexChanged
        Term = CType(Me.cboTerm.SelectedItem, DataRowView).Item("term")
End Sub
[/code]

As you can see... in selectedIndexChange, it changes the variable Term onload, which it shouldnt.

I dont want selectedIndexChange to be executed onLoad.

Answer 10

Why dont you set the SelectedIndex back to 0 after programmatically adding the values?

Or you could also add a button for the user to press when they are ready to run the application, so it will only then go ahead and populate the values.

If that is a bad idea, what about adding it through the designer? (Design view, select combo box, then in the properties window select items and add them) - if you do it this way, items get added and the selectedIndex does not change, pretty much making it not fire the SelectedIndexChange event which is what you would like, correct?

 

Looking at the code again, I see that perhaps you are binding values from some source, comment out the .SelectedValue as I believe this is what is causing the SelectedIndexChanged to fire.

 

The wierd thing is, I just tried a similar code as you had posted but never got the SelectedIndexChange to fire unless I explicitly change the index programmatically (comboBox.SelectedIndex = 1)

Answer 11

Using a flag has been the standard way to deal with this issue for years.

It's not that the event 'should not be fired' it's 'you don't want it to'

Implement the flag option.

Answer 12

Sure, I think I went a bit too overboard! My apologese! :-)

Answer 13

And here I was thinking I'd missed something...

Answer 14

Why not set the handler for the event to nothing, load the control, then set the handler to the routine you want to handle the event, a lot simpler than watching booleans and also reduces execution time as the handler is not executed for each add.

Try:

[code]

RemoveHandler cboTerm.SelectedIndexChanged, addressof cboTerm

    With Me.cboTerm
            .DataSource = Me.MiscDataTableTableAdapter.GetDataByTerm
            .DisplayMember = "term"
            .ValueMember = "term"
            .SelectedValue = Term
        End With

AddHandler cboTerm.SelectedIndexChanged, addressof cboTerm

[/code]

The only extra thing you may then need to do is add a test that items are in the list and select the first member if you want the event to fire to fill in other parts of the form.

Thanks for this question, I have a form interface to our web orders and it loads several lists. Did a walkthrough of the loading and noticed it firing off the handlers for each item loading, complete waste of time. Disabling the handlers, loading the lists, enable handlers and select first item perceptably speeds up loading.

Answer 15

I agree with Mr Whitely.  There are loads of reasons why you would want to set the selectedIndex of a drop-down during startup, and I've used booleans to do exactly this many times without any problem, I see no reason not to use this approach, and one good reason to use it: It's simple

Answer 16

I agree there are many reasons not to action the selectedindexchange event during a load.

Using booleans is fine no sweat, however the code for the eventhandler still executes, what is simpler than not executing it at all, no booleans and no code execution overhead?

Answer 17

Normal use isn't to trap user events, normal use is to trigger whenever the event happens. The event handler does exactly what it's suposed to, fire whenever the event happens. It would lead to some buggy code if events stopped firing when you set someting in code, expecting the coder to explicitly call an event handler each time they set the property (assuming they can call it, or even know it exists)

 

 

Answer 18

Actually, I've been thinking about this issue for a few days, now.

The ability to add and remove handlers is very powerful, and has made coding a few things very easy (adding/removing handlers dynamically to objects created on a whim - nice). I thought I'd give it a try in this situation.

Having played around with it, there are two things:

1. It works

2. It's confusing as heck.

The .NET framework allows us to do a lot of things - basically gives the programmer enough rope to climb in a hole but not out again. Just because you can, doesn't mean you should.

I resorted back to the flag method, leaving the handlers alone - it's much more readable (as long as you call your flag something readable...) and doesn't add any overhead at all.

Once a program becomes extensive, troubleshooting the add/remove handler can become a significant problem. In much the same way that old GDI programmers had to add and remove GDI objects (ugh - I don't know how many times the graphics screwed up on my computer due to funky memory leaks).

 

Answer 19

Try setting your event SelectedIndexChanged handler after setting the data source. Make sure you remove the SelectedIndexChanged  event handler set by the windows form designer from your form's constructor.

This is what your code should look like:

myComboBox.DataSource = dataSource;
myComboBox.DisplayMember = "displayMember";
myComboBox.ValueMember = "valueMember";
 this.myComboBox.SelectedIndexChanged += new System.EventHandler(this.myComboBox_SelectedIndexChanged);

Assuming
private void myComboBox_SelectedIndexChanged(object sender, EventArgs e)
{
       .......................
}
already exists.

Answer 20

Hi there.... my solution:


comboBox1.DataBindings.DefaultDataSourceUpdateMode = DataSourceUpdateMode.Never;
//This will solve u problem!