>>>>nothing I thought would work did. The ThisForm.LostFocus() event doesn't fire when the user changes to another application, only when they change to another form within a vfp app. ThisForm.DeActivate() works the same way. I couldn't find any events at the _VFP level that would do this. I'm not sure a Windows API call would do it either, since VFP doesn't appear to be able to sense it.
>>>>
>>>>Foxheads, how are you doing this?
>>>
>>>Jerry,
>>>
>>>AFAIK, the only way to do this may be pretty hit and miss. What I'd do is use a timer to check the value returned by GetForegroundWindow(). This function returns the window handle of the window the user is currently working in. By comparing this against VFP's main window handle (as returned by MainhWnd() in Foxtools).
>>
>>Opps! Besides relating the timer failures, I forgot to mention that my when my app loses focus it doesn't seem to communicate to it's child windows that it (hence they) have lost focus. That's the problem and there is no "LostFocus" event for the _VFP object.
>
>Jerry,
>
>I'm not sure that I'm correctly understanding you, but GetForegroundWindow() retrurns the top-level form. If VFP's is the one in the foreground GetForegroundWindow() will equal MainhWnd() regardless of what VFP window is currently active and receiving input.

What I'm finding is that the method (ThisForm.LostFocus() or Thisform.Deactivate()) don't fire because while the user may change focus from the VFP app to another app on the desktop, the vfp app doesn't communicate to the child form that the focus has changed. The child form still has the focus, in relation to the app it is in, so the code doesn't fire. IF I were to make MDI forms and switch between them, inside the vfp app, then those two events fire and the method run. Once I change to another app, the GetForeGroundWindow() doesn't fire because the method it is in doesn't fire.