>I have a combobox and I've placed code in the Valid event
>
>If I click the drop-down arrow and then click one of the items, the event fires
>
>If I TAB into the field and use the mouse to select an item the event fires (even if I haven't changed to a different item)
>
>If I click inside the control (not on the drop-down arrow) and keep the mouse button down, then move down to the item I want and now release the mouse button, the valid event does NOT fire. If I do this a second time, the event DOES fire. It appears that if fires/doesn't fire on alternate iterations of the click-hold-release combinations.
>
>This valid code used to reside in the InteractiveChange event, but I moved it because it seemed to fire every time I moved to a new item while in click-hold mode.
>
>Should I have the code in a different event? Am I missing something basic?
I'll assume these are based on the VFP base classes and not subclassed from something else.
Whenever I'm having unexpected things happening in event processing I always put =DODEFAULT() as the first line of any method I'm modifying. The idea being to let the control do whatever it was going to do, before your code fires.
Sometimes I find I've strewn code over a bunch of methods trying to find something that works and forgotten to set back to default. I make sure I've set methods/events to default and then work on one method or event at a time. Also IIRC if nothing but comment(s) remain in event code that will still override the default and potentially cause problems.
There was a seemingly similar problem discussed at
http://www.foxite.com/archives/why-doesnt-my-combobox-valid-fire-0000156042.htm , the OP ended up using LostFocus instead of Valid.
Regards. Al
"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov
Neither a despot, nor a doormat, be
Every app wants to be a database app when it grows up