[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
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Kazuhiro Ito, 2012/05/18
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Eli Zaretskii, 2012/05/19
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Kazuhiro Ito, 2012/05/19
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Eli Zaretskii, 2012/05/19
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, martin rudalics, 2012/05/19
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Eli Zaretskii, 2012/05/19
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Eli Zaretskii, 2012/05/21
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows,
Kazuhiro Ito <=
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Eli Zaretskii, 2012/05/23
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Drew Adams, 2012/05/23
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Kazuhiro Ito, 2012/05/24
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Lennart Borgman, 2012/05/24
- bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows, Eli Zaretskii, 2012/05/28