>
>"When all else fails, read the instructions" (Cahn's Axiom).
>
>MSDN, SetForegroundWindow:
>"Windows 98/Me, Windows 2000 or later:
>With this change, an application cannot force a window to the foreground while the user is working with another window. Instead, SetForegroundWindow will activate the window (see SetActiveWindow) and call the FlashWindowEx function to notify the user. However, on Windows 98, if a nonforeground thread calls SetForegroundWindow and passes the handle of a window that was not created by the calling thread, the window is not flashed on the taskbar. To have SetForegroundWindow behave the same as it did on Windows 95 and Windows NT 4.0, change the foreground lock timeout value when the application is installed. This can be done from the setup or installation application with the following function call:
>
> SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, (LPVOID)0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
>
>This method allows SetForegroundWindow on Windows 98 and Windows 2000 to behave the same as Windows 95 and Windows NT 4.0, respectively, for all applications. The setup application should warn the user that this is being done so that the user isn't surprised by the changed behavior. On Windows 2000, the SystemParametersInfo call fails unless the calling thread can change the foreground window, so this must be called from a setup or patch application. For more information, see Foreground and Background Windows."

Hi Alexander,

Oh yes, I read the instructions, but here's a corollary to Cahn's Axiom: the more you read, the less you understand. Meanwhile, I doubt you'd find any mention of the ShowWindow MINIMIZE/RESTORE approach anywhere in Microsoft's documentation. Do you know if SystemParametersInfo actually works in the context I described, and what specific changes are required to demonstrate this technique in my sample VFP program?

The documentation for SetForegroundWindow lists a number of conditions, any one of which should permit its use. Reading what they say about SystemParametersInfo, the implication appears to be that this is a global setting that should be changed upon installing my application, with a warning to the user. Maybe the SPI_SETFOREGROUNDLOCKTIMEOUT setting could briefly be changed and then restored. But the seeming catch-22 that "the SystemParametersInfo call fails unless the calling thread can change the foreground window" does not inspire confidence in this approach.

Since I had doubts about the feasibility of using SystemParametersInfo, I investigated (briefly) the use of the AllowSetForegroundWindow function and the LockSetForegroundWindow function with the LSFW_UNLOCK option. These functions did not make any difference, and they gave no indication that the problem has anything to do with the SPI_SETFOREGROUNDLOCKTIMEOUT setting, so I haven't pursued SystemParametersInfo further. Since none of this mumbo-jumbo is comprehensible or consistent with the "documentation" of SetForegroundWindow, I decided to search for an answer on Google Groups.

I was amazed at the number of postings about similar problems people have had with the new and "improved" SetForegroundWindow, solutions that don't work, and more possible remedies that might work. I have posted a clear, concise description of an approach the definitely does work. Now I'm tired of experimenting with other "possible" solutions, so I'm asking if anyone can demonstrate a better alternative that they know for a fact does work. Thanks for your suggestion, and I may investigate this approach further if I have the time. With luck, someone who already knows the answer may save us the time of further research and testing.

Mike