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

That's why I said "hit and miss". Win32, being a pre-emptive multi-tasking system should allow the timer to fire. However, the interval will be impacted. When a thread is pre-empted, other threads resume processing. So a VFP timer, if the interval hasn't passed, may or may not fire. Remember that a thread isn't going to get as big a slice if it isn't active. Hence, the reliability problems.

>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. I haven't run into some of these, even though I've heard about them. I fugured out how to restore the UDL link from a post I saw here combined with the research I was doing on the WSH articles for VFUG. I happened to be reading the Windows Script Host Programmers Reference shortly after hearing about the UDL problem and seeing a section on adding items to the New menu.