dwooldridge
New Member
- Joined
- Dec 1, 2011
- Messages
- 18
This thread is spawned from another where I am trying to work through some comboBox problems. It has been suggested that the Change event is the 'default' event or a comboBox or maybe the event of choice. I'm not real clear on what this means but it seems like there are problems concentrating on this event.
My testing seems to say:
1. If we clear the comboBox with VBA code like 'ComboBox.Clear' no events fire.
2. If we set the comboBox value with VBA code like 'ComboBox.Listindex = 2' then the Change and Click events fire.
3. If during execution we move to the control and select a value then the Enter, DropButt******* (if we used the drop down arrow), Change, Click, Dropbutt******* (if we used the drop down arrow),
BeforeUpdate, AfterUpdate, and Exit events fire.
Now wisdom out in the world is tellimg me to put my code into the Change event. But this doesn't make sense to me. What happens if we need to use the BeforeUpdate/AfterUpdate events? The Change event has already fired and our code has already executed - too late to cancel with the BeforeUpdate. Or am I missing something here?
I've seen comments about reading up on a flag to control execution of the event - maybe that relates.
1. Maybe you put the code that needs to be executed into say 'SubA'.
2. Then have a flag like 'boolean DoChangeEventLogic'.
3. When you want to set the comboBox via VBA you set the flag to TRUE and change ListIndex. The Change event fires and has the code 'If DoChangeEventLogic then call SubA'.
4. When you want to set the comboBox manually you navigate to the control. The Enter event fires where you set 'DoChangeEventLogic' to False. You select a new comboBox value (some way) and the Change event fires. The IF statement fails and no code is executed HOWEVER our comboBox does have a new value. The BeforeUpdate eventually fires and if we don't cancel then AfterUpdate and in that event we say 'Call SubA'.
Is this about it? And I guess if you don't need the BeforeUpdate/AfterUpdate then you can just get everything done in the Change event without worrying about flags.
My testing seems to say:
1. If we clear the comboBox with VBA code like 'ComboBox.Clear' no events fire.
2. If we set the comboBox value with VBA code like 'ComboBox.Listindex = 2' then the Change and Click events fire.
3. If during execution we move to the control and select a value then the Enter, DropButt******* (if we used the drop down arrow), Change, Click, Dropbutt******* (if we used the drop down arrow),
BeforeUpdate, AfterUpdate, and Exit events fire.
Now wisdom out in the world is tellimg me to put my code into the Change event. But this doesn't make sense to me. What happens if we need to use the BeforeUpdate/AfterUpdate events? The Change event has already fired and our code has already executed - too late to cancel with the BeforeUpdate. Or am I missing something here?
I've seen comments about reading up on a flag to control execution of the event - maybe that relates.
1. Maybe you put the code that needs to be executed into say 'SubA'.
2. Then have a flag like 'boolean DoChangeEventLogic'.
3. When you want to set the comboBox via VBA you set the flag to TRUE and change ListIndex. The Change event fires and has the code 'If DoChangeEventLogic then call SubA'.
4. When you want to set the comboBox manually you navigate to the control. The Enter event fires where you set 'DoChangeEventLogic' to False. You select a new comboBox value (some way) and the Change event fires. The IF statement fails and no code is executed HOWEVER our comboBox does have a new value. The BeforeUpdate eventually fires and if we don't cancel then AfterUpdate and in that event we say 'Call SubA'.
Is this about it? And I guess if you don't need the BeforeUpdate/AfterUpdate then you can just get everything done in the Change event without worrying about flags.
