Alexander,

Thanks very much for testing on XP and reporting the results. I assume you mean that XP has the same problem as Win2K with SetForegroundWindow, and that the ShowWindow MINIMIZE/RESTORE hack also works under XP.

Where this problem comes up is in an application whose purpose is to save and restore a configuration of previously launched Windows applications. The sample code I posted is one of the simplest possible illustrations: VFP launches one or more Explorer windows, which it controls in various ways (e.g. initialization at the very least). Is this not a legitimate concept?

All I'm trying to do is restore the focus to the "main" application that just opened another application. There is no user action in progress in this "child" Explorer window, yet it refuses to relinquish the focus back to the very application that just launched it. What SetForegroundWindow was originally designed to do seems to be precisely what is called for, and the fact that SetForegroundWindow was "re-designed" not to perform this function does nothing to persuade me that maybe I should reconsider and settle for some entirely different functionality.

So I've posed this as a simple, practical question: is there a better alternative than ShowWindow MINIMIZE/RESTORE? If I find one, I'll let you know. If someone else has any ideas, don't just speculate, please test it out and post the code for a better solution.

TIA

Mike

>Mike,
>
>In my comment I wanted to say that this behavior of SetForegroundWindow is "by design" and attempts to evade this behaviour may be not a good idea.
>There are two reasons why SetForegroundWindow may fail:
>1. The foreground is locked (as in case of explorer.exe). Calls to SetForegroundWindow are disabled by calling the LockSetForegroundWindow. Probably application has some reasons for it.
>2. The timeout since last user input hasn't expired. It means that user is interacting with application and switching to another application may be undesirable. For example, your code will work with notepad.exe till user is not interacting with it.
>BTW, your code works on WindowsXP.
>
>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.