Why is Setforegroundwindow() still working?
Alec Lewis
to make Setforegroundwindow() bring a window up
even on Windows 98, right?
My question is the opposite. I'm trying to figure
out why the following code is still causing a window
to pop up and steal focus, etc. instead of just
flashing the taskbar icon like the way it is
supposed to on Windows 98:
// m_dlg is a modeless, CDialog-derived class member
// variable. I've already called m_dlg.Create(IDD_DIALOG1).
// I haven't called ShowWindow() on it yet...
m_dlg.SetWindowPos(NULL, 0,0,0,0, SWP_NOZORDER |
SWP_NOMOVE |
SWP_NOSIZE |
SWP_NOACTIVATE |
SWP_SHOWWINDOW);
// PROBLEM: If the window wasn't visible in the
// taskbar prior to the previous call then this next
// call makes the dialog popup in your face. If
// the dialog already was on the taskbar then I do
// get the flash...
m_dlg.SetForegroundWindow();
Can anyone help me get the flashing behavior *always*
thanks, Alec.
William DePalo [MVP]
>My question is the opposite. I'm trying to figure
>out why the following code is still causing a window
>to pop up and steal focus, etc. instead of just
>flashing the taskbar icon like the way it is
>supposed to on Windows 98:
Is your dialog in the foreground when it makes the call? If so, SFW()
behaves as it did before.
Regards,
Will
Alec Lewis
provide earlier.
It turns out that the app happens to be a "Tray application".
It doesn't have a window or button of its own in the tasklist,
but it will create and pop up a modeless dialog which is
the one that seems to still be able to steal the foreground.
The fact that the app itself isn't on the tasklist seems
to be significant. If I write a regular desktop app with
a window of its own in the tasklist then this same
popup modeless dialog starts to obey the "flashing" rules
of setforeground window. A mystery...
William DePalo [MVP] wrote in message ...
Matt Arnold
>provide earlier.
>
>It turns out that the app happens to be a "Tray application".
>It doesn't have a window or button of its own in the tasklist,
>but it will create and pop up a modeless dialog which is
>the one that seems to still be able to steal the foreground.
>
>The fact that the app itself isn't on the tasklist seems
>to be significant. If I write a regular desktop app with
>a window of its own in the tasklist then this same
>popup modeless dialog starts to obey the "flashing" rules
>of setforeground window. A mystery...
Hmm, perhaps when there's no Taskbar button to flash (your app has only
a notification icon), Windows has no choice but to revert to the old
behavior of SetForegroundWindow(). I mean, I guess it has to do
"something"?
However, IMO, what should really happen in this case is flashing of the
notification icon, eh?
Regards,
Matt Arnold
Professional Music Products
Mark of the Unicorn, Inc.
http://www.motu.com
/////////////////////////////////////////////////////////////////////
////////////// Change "garbage" to "motu" to email me! //////////////
/////////////////////////////////////////////////////////////////////
Pursuant to US Code, Title 47, Chapter 5, Subchapter II, Sec. 227 any
and all unsolicited commercial email sent to this address is subject
to a download and archival fee in the amount of $500.00 US. Emailing
this address denotes acceptance of these terms. For more information
see http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D.
William DePalo [MVP]
>to be significant. If I write a regular desktop app with
>a window of its own in the tasklist then this same
>popup modeless dialog starts to obey the "flashing" rules
>of setforeground window. A mystery...
I don't know for sure. This is a wild-ass guess:
There are two "well known" quirks with respect to tray icons that are
"documented" in the MS knowledge base. One is that an application which
wants to track a pop-up menu _is supposed_ to call SetForegroundWindow()
before it does so. The kb article describes this requirement as being "by
design". And if you think about it, it makes sense. That is to say that the
click in the tray would be expected to activate the taskbar. On the other
hand the task that "owns" the tray icon needs to put up the menu. In every
other case I can think of, menus are put up by the active application (in
fact they disappear on activation of anything else).
I offer that long-winded explanation to support the case that perhaps the
shell allows an application that owns a tray icon to "steal" the foreground
based on the fact that the theft was "approved" by the user who clicked it.
Regards,
Will
Strohm Armstrong
window. The taskbar then calls AllowSetForegroundWindow to allow the "owner"
of the tray icon to use SetForegroundWindow and have it work correctly.
The important thing to remember is that the current foreground thread an use
SetForegroundWindow and it will behave in the old manner. If the thread that
calls SetForegroundWindow is not the current foreground thread, then
SetForegroundWindow behaves in the new manner.
Also, only the current foreground thread can call AllowSetForegroundWindow
and have it be effective.
William DePalo [MVP] <depalow...@compuserve.com> wrote in message
news:OBks$z8T#GA....@uppssnewspub04.moswest.msn.net...
Alec Lewis
the SetForegroundWindow() "fix" for my context menu as
described in the knowledge base. However I'm still seeing
behavior that I don't think is explained by the
taskbar being in the foreground:
The tray app is displaying the the modeless dialog
"asynchronously". That is as a result of a timer that
goes off internally at which point I call:
SetWindowPos(&wndBottom,... ,SWP_SHOWWINDOW | SWP_NOACTIVATE)
SetForegroundWindow().
So I can be typing in Wordpad and when the timer goes off
the tray app's dialog pops up and steals the focus just
like on Win95. The odd part is that this only happens
if the dialog was previously not visible in the taskbar.
If dialog is already on the taskbar(i.e that the SetWindowPos()
is a noop) then the setforeground call works as it should
on Win98.
As someone suggested I put a delay after the SetWindowPos()
call before calling SetForegroundWindow(). Unfortunately
that didn't make any difference.
Thanks everyone for your help on this. I've run out of
time pursuing the problem and have to move on. if anyone
wants to see my example program that demos the problem
just let me know: alec_...@hotmail.com
thanks, Alec
Strohm Armstrong wrote in message ...