[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11513: 24.1.50; raise-frame never raise the foreground window on Win

From: Kazuhiro Ito
Subject: bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows
Date: Wed, 23 May 2012 19:48:59 +0900
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Goj┼Ź) APEL/10.8 EasyPG/1.0.0 Emacs/24.1.50 (i386-mingw-nt6.1.7600) MULE/6.0 (HANACHIRUSATO)

At Mon, 21 May 2012 22:12:46 +0300,
Eli Zaretskii wrote:
> It's a very elusive problem.  I managed to reproduce it on 1 system
> out of 3 to which I have constant access, and even that only for a few
> minutes and under some conditions.  E.g., when lowering the frame left
> only the left side of the Emacs frame visible, the bug would manifest
> itself; whereas when its right side was visible, it won't.  And once I
> reshuffled the other windows a bit, the bug disappeared and I couldn't
> reproduce it anymore.
> Do you get the faulty behavior consistently?

raise-frame always make the unexpected result when Emacs frame is
the foreground window (I mean Emacs frame is colored as active window)
and behind of other application window(s).  And, as I described
previously, If Emacs frame is not the foreground window raise-frame
correctly works.

> If so, what's your value of this Registry key:
>   HKEY_CURRENT_USER\Control Panel\Desktop\UserPreferencesMask

Key's value is '98 12 07 80 12 00 00 00'.

>  . The documentation of SetForegroundWindow
> (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633539%28v=vs.85%29.aspx)
>    lists quite a few of conditions under which the function will
>    succeed; are you sure at least one of them was true when you tried?
>    can you look at the value of 'retval' after the function returns
>    without bringing the frame to the foreground?

I believe that my test case qualifies some of conditions and I
confirmed SetForegroundWindow returns 1 even when the unexpected
result has been made.

>  . This page:
> http://stackoverflow.com/questions/1544179/what-are-the-differences-between-bringwindowtotop-setforegroundwindow-setwindo
>    seems to tell that BringWindowToTop might fail as well, if it is
>    applied to a child window.  What does this mean in terms of Emacs
>    frames?

I don't know exactly, but I think a child window is a windows created
with WS_CHILD style.  In Emacs, w32_createscrollbar would make scroll
bar as a child window.

Kazuhiro Ito

reply via email to

[Prev in Thread] Current Thread [Next in Thread]