Sequence of events in Excel ComboBox

[Tony Furnivall]

I'm puzzled why the Change and CLick events are fired in reverse order, in an Excel ComboBox.

Here's a situation:

I have a ComboBox containing a list of items. In order to select one I click on the drop-down button, and then click on an entry in the list. At that point the entry is transferred to the text-box area of the control. So I've done two clicks. The events I would expect to see would be:

DropButtonClick

Click

Change

Instead, what happens is:

DropButtonCLick

Change

Click

There is no member which allows the Change event to indicate that it has happened as part of an earlier Click. Of course, if you processed them in the order which I believe to be more sensible, then the simple fact of the Click event would allow me to save that event, and modify the processing in the Change event. (How much more wonderful if the ComboBox itself indicated the state of the list, which is really what we need to get).

Has anyone else experienced this problem? And if so, how have you solved it?

Thanks,

Tony

[#2]

I am facing one issue with height of list for combobox in excel vba forms. When I am assigning the rowsource as a dynamic list, with offset function, the list height is coming fine, however not sure, how can I fix the height of a static list, where we mention the rowsource, in the combobox properties while designing the form. I want user to not to get an option to scroll further after the actual list values.

[#3]

@Sud1pt why are you answering a question with a question.  Start your own thread instead of hijacking this one,

[#4]

The solution I finally adopted was somewhat akin to capturing the Shift parameter on MouseDown and MouseUp. In that model we save the Shift value in an external variable, and then simply reference it during the Click or DoubleClick event.

So, in the case in point, we capture the 'fact' of the DropButton Click by setting a value in the Tag field (this keeps it internal to the control). Then by interrogating the Tag field we can determine if the Change event is fired by a Click on the list or by typing in the ComboBox text area.

It's messy - it removes the Tag from any other use (which was no loss for me), and requires set up and cleanup on the Enter and Exit events. However, it gave me most of what I needed! Another possibility I explored (which was Really Messy) was tombine a TextBox, a Button (for the DropDown) and a Listbox, and manage their visibility myself, rather than allowing Excel to do this.

I know CoomboBoxes are "legacy" controls, but I can't imagine how exposing the ListVisible property (which must be there to know whether to close the list or not!) would create problems.

Like most software, support does not generate revenue, and fixing 'old' problems is considered unglamorous.

How wrong can they be!

Tony