Re: BringWindowToFront/SetForegroundWindow problem

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From the documentation I have (the VS2005 documentation), it appears that these
restrictions apply only to Windows 98/Me; for 2000, the only limitation seems to be that
no menus are active. No menus are active. My docs don't mention those restrictions for
2000 or XP. We're running XP SP2. Or is the documentation just poorly written?
joe
On Mon, 5 Feb 2007 01:42:06 -0600, "Scot T Brennecke" <ScotB@xxxxxxxxxxxxxxxxxx> wrote:

Joe,
Some things come to mind that maybe are relevant. In your SWP call, you are hiding the
full-screen window and pushing it to the bottom before trying to bring up the previous app. This
means you no longer have the foreground window status, and thus lose some ability to bring another
app to the foreground. Check out this blurb from the MSDN that addresses the privilege of setting a
window to the foreground:
"Windows 98/Me/2000/XP: The system restricts which processes can set the foreground window. A
process can set the foreground window only if one of the following conditions is true:
a.. The process is the foreground process.
b.. The process was started by the foreground process.
c.. The process received the last input event.
d.. There is no foreground process.
e.. The foreground process is being debugged.
f.. The foreground is not locked (see LockSetForegroundWindow).
g.. The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in
SystemParametersInfo).
h.. Windows 2000/XP: No menus are active.
Windows 2000/XP: A process that can set the foreground window can enable another process to set the
foreground window by calling the AllowSetForegroundWindow function, or by calling the
BroadcastSystemMessage function with the BSF_ALLOWSFW flag. The foreground process can disable calls
to SetForegroundWindow by calling the LockSetForegroundWindow function."


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:n6cds21rhlk3c341d4cd4gio0n0eerui8n@xxxxxxxxxx
I have been bashing at this all day, and have not made any progress. There's something
obvious I'm missing.

Basic scenario: when an external event happens, a full-screen window is brought up and
some appropriate state is displayed. When the external state goes away, the screen
reverts to whatever app was running. Note that this is a client specification which has a
serious design justification, so I can't change the spec. It is not a general windows
workstation situation, but a dedicated process-control system.

The app is running in the background, waiting for an alarm notification from the hardware.
When the notification arrives, the window is set as HWND_TOPMOST. This causes it to
receive a WM_ACTIVATEAPP with the thread ID of the formerly-running app as the LPARAM. I
save the LPARAM for later reactivation of the window in that thread.

When the hardware alarm goes away, the app does a SetWindowPos(HWND_BOTTOM, SWP_HIDEWINDOW
| SWP_NOACTIVATE), and it then receives a WM_ACTIVATEAPP message with wParam FALSE. At
this point, I need to bring the previous app to the front. All apps that are running in
this dedicated environment have exactly one top-level window (Word is not an option here!)
so what I did was call EnumThreadWindows passing in the thread ID received on the
WM_ACTIVATEAPP that activated this app. This correctly locates the window that had been
previously running as the active app. I can see this because I see the window handle and
even the correct window class being printed out via TRACE statements. Good so far.

Next, I try to make this window--the app that was preempted by the alarm condition--become
active, and that's where things start falling apart. SetForegroundWindow and
BringWindowToTop fail to make the window active and have it receive the focus. It remains
in the "inactivated" color on its title bar.

So I built a little app to simulate the generic app. This app logs all relevant messages
in a listbox. I see a sequence of messages when it loses control,
WM_NCACTIVATE (0,0)
WM_ACTIVATE (0, 0)
WM_ACTIVATEAPP (0, 1FB4)
WM_KILLFOCUS(0,0)
------------------------------------
WM_NCPAINT(1, 0)
WM_ERASEBKGND(HDC, 0)
WM_PAINT(0,0)

and it stops there. So what I did was SendMessage a Registered Window Message to it
right before the BringWindowToTop. Nothing happens. In fact, there is no indication that
the message loop has activated to handle the Registered Window Message.

Note: because the alarm app fills the entire screen, I believe that the NCPAINT,
ERASEBKGND, and PAINT messges actually are part of the window becoming visible when the
alarm window goes away.

But here's the really weird thing. If I click on ANY OTHER APP (e.g., spy++, which I was
also running, or Alt-Tab to task manager), the Registered Window Message comes out:
0xc137 (0,0)
But the app does not activate! Spy++ reports the same behavior in its message trace. The
message queue is apparently blocked for some reason (this app is the minimalist example
created by the AppWizard, with a simple GetMessage/DispatchMessage loop; there is nothing
sophisticated going on here at all!)

None of this corresponds to any behavior I have seen in the past. Neither
SetForegroundWindow nor BringWindowToTop have any effect. TRACE statements in the alerter
show that is receives a WM_ACTIVATEAPP(FALSE, threadid), finds the correct window to
activate, sends it a registered window message, brings it to the top or sets it as the
foreground, but the window receives no further messages until something else happens.

The thread of the target window is not blocked (except on the GetMessage call).

Anyone have any ideas or suggestions here? I've run out of ideas at this point.
joe
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages