>>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).

Thanks, George,
I've considered something along those lines but my experience with timers is that when the vfp app loses focus the timer frequently quits 'timing', and doesn't resume until the app has focus again. Doevents and the AutoYield properies didn't seem to reliably help the timer while it was out of focus.

BTW, appreciated your article, "Restore Unsiversal Data Link Affected by SP4", in the VFUG newsletter this month! The SP4 seems to have effected a lot of behaviors on various controls. I've had "IF A = B" fail, even when the debugger showed that A & B where both integers and equal. I've had to remove ALLTRIM() from within INLIST() and CASE functions, and other stuff. Apps that had been working fine since VFP6 came out were falling over.
Thanks again,
Jerry