>>>>So, what you're saying is the application should behave differently than all other Windows applications?
>>>>
>>>>
>>>>>Disagree totally.
>>>
>>>Of course the problem as described isn't really a problem with double-click events per se. From what I can tell from the description, there was enough of a "gap" in time between the clicks that the first click is indeed registered by the dropdown (which then "retracted") and the following click was registered by a control that was previously covered by dropdown. I've noticed that there are some users which get into the habit of trying to double-click *everything* -- probably based on remember that they've got to double-click a desktop icon. Unfortunately this means they tend to double-click input fields, labels, control buttons, treeviews, etc. There are variations to this theme -- they may not double-click everything (they learned at some point that double-clicking on command buttons doesn't give what they want) -- so they tend to double-click only on items with a picture on it (which unfortunately means they still double-click on command buttons if it has a picture on it, and double-click on toolbar items).
>>>
>>>One idea is to code the application so that it would "eat" the extraneous clicks -- perhaps by somehow having the main application window to first filter all events, filtering according to timing of events, then either "eat" or pass through to child windows the click events. Unfortunately I can't see any *clean* and *reliable* way of doing such a thing. Perhaps you might be able to get it to work with built-in controls, but it will likely fail on ActiveX controls, and probably won't work with any dialogs not built as a FoxPro screen -- which will mean that the new behavior is likely to be *inconsistent* even within your application (and definitely not with the rest of Windows).
>>
>>SET DEBATE ON
>>
>>I strongly advice to NOT PLEASE the user by trying to eat the second click. That is surely not the way to go. Microsoft's design is clear and should be consistent anywhere. Eating clicks in a vfp-app makes the app idiosyncratic.
>>
>>However, there is another solution. The developer can take care that there is no object below the combobox items at all.
>
>The tricky part is that the dropdown may not always drop down -- it sometimes drops up (when it is close enough to bottom of screen so that there isn't room below). That would mean you may have to leave space above (just in case) as well as below. Perhaps it might be easier to forgo using dropdown lists? (and in situations where the list has the potential to grow very long and require scrolling, then dropdown probably isn't a good control to be using in such a case)

One can limit the number of displayed items, although that's not my favorite type of user interfacing. I'm still of opinion that the user should try to live with it.