Increasing value of _DBLCLICK would probably be trading off one problem for another one. Instead of triggering CLICK() events, now you're likely to trigger DBLCLICK(). The other bit that I'm not sure of is if increasing the value of _DBLCLICK would mean that it takes longer for the dropdown to "retract" (so that the second click would land on the dropdown rather than the control that was behind the dropdown at the time of the first click) -- I'd have to check if that is the case or not..

>The fix is easy then. Change the value of _DBLCICK
>
>
>>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).