On Tue, 03 Apr 2007 11:28:08 -0700, Peter Ritchie [C# MVP]
<PR****@newsgroups.nospamwrote:
[...]
Could be my concept of "foreground process" (in that it has the
foreground window) is flawed.
That's probably the case. I'm not actually aware of any official
definition of "foreground process", though obviously there must be one for
the documentation to make any sense. However, it seems to me that
"foreground process" could easily include simply the process that was just
started when no other changes to focus has been made. After all, if the
process starting up isn't already the foreground process when it creates
its first window, it's hard to see how the rules would allow its window to
wind up the foreground window. :)
Or, it could be that SetForegroundWindow always works if
a process is attempting a call on SetForegroundWindow on another
instance of the same application and simply isn't documented.
It would be easy enough to test for that condition. Just write a second
application that uses SetForegroundWindow on the first. If indeed there's
a special case for the process being the same application, then using a
second application will result in a failure to set the first application
as the foreground application.
If it works, then that would indicate that indeed a process can be the
foreground process without actually having a window.
Of course, all of this said, IMHO it's a bad idea _generally_ to use
SetForegroundWindow. There's a reason that the rules are complex and
there are many ways for it to not work. That is, it's rude to the user to
bring a new process to the foreground without the user's explicit
instructions or consent.
IMHO, it's almost always better to use SetActiveWindow instead. I think
that in the situation described by the OP the SetForegroundWindow is more
appropriate, but I hope anyone reading through this thread will note that
it's a very specific situation and the solution does not apply to all
other situations.
Pete