>>>This LostFocus of the textbox doesn't fire either. It seems like the Active X control stops all usual firing of events. Where would I put the code for the first suggestion? The second sounds like it wont work.
>>
>>Well, you might try updating the 'last' control property in the GotFocus of the textbox (obviously, it had to get focus at some point) and then check it when your ActiveX control receives focus.
>>
>>As to why you can put a VFP control on top if an ActiveX control, there's no provision for containership by an ActiveX control. VFP native controls are not 'standard' Windows controls, in that they do not each have their own hWND reference, and the ActiveX control doesn't know how to manipulate them directly.
>>
>>You might also try setting the AutoYield property of the Application object to .F. to see if things behave a bit better by keeping ActiveX control events from firing between lines of VFP code. The ActiveX control will be given an opportunity to fire during any VFP wait state.
>
>This sure seems like a lot of overhead. I'm thinking of removing the Active X control and not even use it. Is this problem occur in all Active X controls?

Not all, but the vast majority of ActiveX controls do require the disabling of the AutoYield property. The details are discussed in the docs under the AutoYield property entry.

The problem of ActiveX containers in VFP is pretty widespread - there are a couple of MSKB entries on this, at least one of which was referenced by Erik Moore during the past day or two when discussing the Coolbar ActiveX control.