* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows @ 2012-05-18 21:06 Kazuhiro Ito 2012-05-19 8:02 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Kazuhiro Ito @ 2012-05-18 21:06 UTC (permalink / raw) To: 11513 When I start Emacs with -Q option nd evaluate the below code, I get unexpected result. (let ((frame (selected-frame))) (lower-frame frame) ;; If we change the foreground window while sleeping, raise-frame ;; correctly works. (sleep-for 5) (raise-frame frame)) Result: raise-frame never raise the frame if the selected frame is the foreground window. If other frame or application is the foreground window, raise-frame works as expected. I guess SetForegroundWindow function does not modify Z-order when the window is already foreground. Below patch or similar workaround would be needed. === modified file 'src/w32fns.c' --- src/w32fns.c 2012-05-11 06:39:26 +0000 +++ src/w32fns.c 2012-05-18 11:24:26 +0000 @@ -3681,6 +3760,8 @@ retval = SetForegroundWindow ((HWND) wParam); + BringWindowToTop ((HWND) wParam); + /* Detach from the previous foreground thread. */ if (foreground_thread) AttachThreadInput (GetCurrentThreadId (), -- Kazuhiro Ito ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-18 21:06 bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows Kazuhiro Ito @ 2012-05-19 8:02 ` Eli Zaretskii 2012-05-19 12:02 ` Kazuhiro Ito 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2012-05-19 8:02 UTC (permalink / raw) To: Kazuhiro Ito; +Cc: 11513 > Date: Sat, 19 May 2012 06:06:09 +0900 > From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> > > When I start Emacs with -Q option nd evaluate the below code, I get > unexpected result. > > (let ((frame (selected-frame))) > (lower-frame frame) > ;; If we change the foreground window while sleeping, raise-frame > ;; correctly works. > (sleep-for 5) > (raise-frame frame)) > > Result: raise-frame never raise the frame if the selected frame is the > foreground window. I cannot reproduce this on my Windows XP system. When I evaluate the above, the Emacs frame is correctly lowered (i.e. goes behind the other window(s)), and then is brought into the foreground several seconds later. > If other frame or application is the foreground window, raise-frame > works as expected. What exactly do you mean by "If other frame or application is the foreground window"? If the Emacs frame is the only foreground window (i.e. all the others are iconified) when I evaluate the recipe, then the Emacs frame is neither lowered nor raised, which I think is the expected behavior. So please specify more precisely the conditions for reproducing this problem, in terms of what other windows should or should not be present on the display before evaluating the recipe code. Perhaps the recipe lacks some specific mouse gestures to achieve the required effect? Also, please provide the details normally collected by "M-x report-emacs-bug RET". They are important. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-19 8:02 ` Eli Zaretskii @ 2012-05-19 12:02 ` Kazuhiro Ito 2012-05-19 12:42 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Kazuhiro Ito @ 2012-05-19 12:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11513 > > When I start Emacs with -Q option nd evaluate the below code, I get > > unexpected result. > > > > (let ((frame (selected-frame))) > > (lower-frame frame) > > ;; If we change the foreground window while sleeping, raise-frame > > ;; correctly works. > > (sleep-for 5) > > (raise-frame frame)) > > > > Result: raise-frame never raise the frame if the selected frame is the > > foreground window. > > I cannot reproduce this on my Windows XP system. When I evaluate the > above, the Emacs frame is correctly lowered (i.e. goes behind the > other window(s)), and then is brought into the foreground several > seconds later. The problem also occurs with pre-compiled pretest binary (*1) on Windows XP and Windows 7 (Professional, x64) system. In my environment, when I evaluate the above code, Emacs frame is correctly lowered too, but is not brought into the foreground. Emacs frame keeps behind the other application window(s). (*1) http://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-24.0.97-bin-i386.zip > > If other frame or application is the foreground window, raise-frame > > works as expected. > > What exactly do you mean by "If other frame or application is the > foreground window"? If I change foreground application from Emacs to other application via ALT + TAB or mouse click while Emacs runs sleep-for function in the above code, Emacs frame is brought into the foreground several seconds later. that is the expected result. > So please specify more precisely the conditions for reproducing this > problem, in terms of what other windows should or should not be > present on the display before evaluating the recipe code. Perhaps the > recipe lacks some specific mouse gestures to achieve the required > effect? 1. Launch other Windows application (e.g. explorer, Command Prompt). 2. Start Emacs with -Q option. 3. Move Emacs frame to make it to overlap other application window(s) with mouse drag. 4. Yank the below code into *scratch* buffer. (let ((frame (selected-frame))) (lower-frame frame) (sleep-for 5) (raise-frame frame)) 5. Evaluate it with C-j. 6. Keep away from keyboard and mouse until Emacs finishes evaluation. Result: Emacs frame is behind other application window(s). Expected result: Emacs frame is in front of other application window(s). > Also, please provide the details normally collected by > "M-x report-emacs-bug RET". Here is the details with pretest binary. This bug report will be sent to the Bug-GNU-Emacs mailing list and the GNU bug tracker at debbugs.gnu.org. Please check that the From: line contains a valid email address. After a delay of up to one day, you should receive an acknowledgement at that address. Please write in English if possible, as the Emacs maintainers usually do not have translators for other languages. Please describe exactly what actions triggered the bug, and the precise symptoms of the bug. If you can, give a recipe starting from `emacs -Q': If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. For information about debugging Emacs, please read the file f:/emacs-24.0.97/etc/DEBUG. In GNU Emacs 24.0.97.1 (i386-mingw-nt6.1.7601) of 2012-05-17 on MARVIN Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --with-gcc (4.6) --no-opt --enable-checking --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-3.0.9/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: JPN value of $XMODIFIERS: nil locale-coding-system: cp932 default enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: <language-change> C-y C-j <escape> x r e p o r t < return> Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Mark set Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date japan-util tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces cus-face files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process multi-tty emacs) -- Kazuhiro Ito ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-19 12:02 ` Kazuhiro Ito @ 2012-05-19 12:42 ` Eli Zaretskii 2012-05-19 12:56 ` martin rudalics 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2012-05-19 12:42 UTC (permalink / raw) To: Kazuhiro Ito; +Cc: 11513 > Date: Sat, 19 May 2012 21:02:21 +0900 > From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> > Cc: 11513@debbugs.gnu.org > > 1. Launch other Windows application (e.g. explorer, Command Prompt). > 2. Start Emacs with -Q option. > 3. Move Emacs frame to make it to overlap other application window(s) > with mouse drag. > 4. Yank the below code into *scratch* buffer. > > (let ((frame (selected-frame))) > (lower-frame frame) > (sleep-for 5) > (raise-frame frame)) > > 5. Evaluate it with C-j. > 6. Keep away from keyboard and mouse until Emacs finishes evaluation. > > Result: Emacs frame is behind other application window(s). > > Expected result: Emacs frame is in front of other application > window(s). Thanks. I get the expected result on my system, with the latest pretest binary. The only differences I could think of that could explain why we get different results are (1) I built the pretest myself (will try the binary you used later); and (2) some Windows configuration changes, either on your system or on mine, that make our systems behave differently. Would other Windows users please try reproducing this problem on their machines? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-19 12:42 ` Eli Zaretskii @ 2012-05-19 12:56 ` martin rudalics 2012-05-19 13:47 ` Eli Zaretskii 2012-05-21 19:12 ` Eli Zaretskii 0 siblings, 2 replies; 13+ messages in thread From: martin rudalics @ 2012-05-19 12:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Kazuhiro Ito, 11513 > Would other Windows users please try reproducing this problem on their > machines? Not reproducible on Windows XP. Tested with release and trunk, both built by myself. martin ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-19 12:56 ` martin rudalics @ 2012-05-19 13:47 ` Eli Zaretskii 2012-05-21 19:12 ` Eli Zaretskii 1 sibling, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2012-05-19 13:47 UTC (permalink / raw) To: martin rudalics; +Cc: kzhr, 11513 > Date: Sat, 19 May 2012 14:56:57 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: Kazuhiro Ito <kzhr@d1.dion.ne.jp>, 11513@debbugs.gnu.org > > > Would other Windows users please try reproducing this problem on their > > machines? > > Not reproducible on Windows XP. Tested with release and trunk, both > built by myself. Thanks for testing. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-19 12:56 ` martin rudalics 2012-05-19 13:47 ` Eli Zaretskii @ 2012-05-21 19:12 ` Eli Zaretskii 2012-05-23 10:48 ` Kazuhiro Ito 1 sibling, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2012-05-21 19:12 UTC (permalink / raw) To: martin rudalics; +Cc: kzhr, 11513 > Date: Sat, 19 May 2012 14:56:57 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: Kazuhiro Ito <kzhr@d1.dion.ne.jp>, 11513@debbugs.gnu.org > > > Would other Windows users please try reproducing this problem on their > > machines? > > Not reproducible on Windows XP. Tested with release and trunk, both > built by myself. 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? If so, what's your value of this Registry key: HKEY_CURRENT_USER\Control Panel\Desktop\UserPreferencesMask Anyway, back to the discussion, I notice that: . 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? . 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? . There are quite a few discussions about this that Google picks up, and most of them clearly say that using BringWindowToTop isn't sufficient, either. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-21 19:12 ` Eli Zaretskii @ 2012-05-23 10:48 ` Kazuhiro Ito 2012-05-23 16:20 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Kazuhiro Ito @ 2012-05-23 10:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11513 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-23 10:48 ` Kazuhiro Ito @ 2012-05-23 16:20 ` Eli Zaretskii 2012-05-23 16:38 ` Drew Adams 2012-05-24 6:04 ` Kazuhiro Ito 0 siblings, 2 replies; 13+ messages in thread From: Eli Zaretskii @ 2012-05-23 16:20 UTC (permalink / raw) To: Kazuhiro Ito; +Cc: 11513 > Date: Wed, 23 May 2012 19:48:59 +0900 > From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> > Cc: martin rudalics <rudalics@gmx.at>, 11513@debbugs.gnu.org > > > 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. But the default behavior on Windows is that a window that is lowered loses its focus. You need to click into it to get focus there. So how come a lowered window still has focus for you? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-23 16:20 ` Eli Zaretskii @ 2012-05-23 16:38 ` Drew Adams 2012-05-24 6:04 ` Kazuhiro Ito 1 sibling, 0 replies; 13+ messages in thread From: Drew Adams @ 2012-05-23 16:38 UTC (permalink / raw) To: 'Eli Zaretskii', 'Kazuhiro Ito'; +Cc: 11513 > But the default behavior on Windows is that a window that is lowered > loses its focus. You need to click into it to get focus there. Really? Pick your favorite release, e.g. Emacs 23.3 or the latest Emacs 24 pretest, and do this: emacs -Q C-x 5 2 Move a frame if necessary, so they overlap. M-: (lower-frame) The frame with the focus, where you typed `M-:', is lowered (moved to the back), but it still has the input focus (is still selected). `M-x' and other input show up in its minibuffer, and its title bar is highlighted to indicate that it is selected. So I don't understand what you mean. It sounds like what you are saying contradicts what I see. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-23 16:20 ` Eli Zaretskii 2012-05-23 16:38 ` Drew Adams @ 2012-05-24 6:04 ` Kazuhiro Ito 2012-05-24 16:01 ` Lennart Borgman 2012-05-28 17:28 ` Eli Zaretskii 1 sibling, 2 replies; 13+ messages in thread From: Kazuhiro Ito @ 2012-05-24 6:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11513 > > 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. > > But the default behavior on Windows is that a window that is lowered > loses its focus. You need to click into it to get focus there. So > how come a lowered window still has focus for you? When I run lower-frame function in Emacs frame interactively, Emacs frame is brought behind of other application window(s) but has focus. Key inputs are passed to lowered frame. I tested 4 Windows PC, and all PCs show the same behavior. -- Kazuhiro Ito ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-24 6:04 ` Kazuhiro Ito @ 2012-05-24 16:01 ` Lennart Borgman 2012-05-28 17:28 ` Eli Zaretskii 1 sibling, 0 replies; 13+ messages in thread From: Lennart Borgman @ 2012-05-24 16:01 UTC (permalink / raw) To: Kazuhiro Ito; +Cc: 11513 On Thu, May 24, 2012 at 8:04 AM, Kazuhiro Ito <kzhr@d1.dion.ne.jp> wrote: >> > 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. >> >> But the default behavior on Windows is that a window that is lowered >> loses its focus. You need to click into it to get focus there. So >> how come a lowered window still has focus for you? > > When I run lower-frame function in Emacs frame interactively, Emacs > frame is brought behind of other application window(s) but has focus. > Key inputs are passed to lowered frame. I tested 4 Windows PC, and > all PCs show the same behavior. The same happens for me. On the other hand the doc string for lower-frame does not say that the frame should loose focus. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows 2012-05-24 6:04 ` Kazuhiro Ito 2012-05-24 16:01 ` Lennart Borgman @ 2012-05-28 17:28 ` Eli Zaretskii 1 sibling, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2012-05-28 17:28 UTC (permalink / raw) To: Kazuhiro Ito; +Cc: 11513-done > Date: Thu, 24 May 2012 15:04:59 +0900 > From: Kazuhiro Ito <kzhr@d1.dion.ne.jp> > Cc: rudalics@gmx.at, 11513@debbugs.gnu.org, drew.adams@oracle.com > > > > 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. > > > > But the default behavior on Windows is that a window that is lowered > > loses its focus. You need to click into it to get focus there. So > > how come a lowered window still has focus for you? > > When I run lower-frame function in Emacs frame interactively, Emacs > frame is brought behind of other application window(s) but has focus. > Key inputs are passed to lowered frame. I tested 4 Windows PC, and > all PCs show the same behavior. Sorry, I was confused. You are right, the focus isn't lost. Anyway, I don't think it is a good idea to modify the reaction to the WM_EMACS_SETFOREGROUND message, because it is also used by x-focus-frame, which is not supposed to raise the frame to the top of the Z-order, unless it is strictly necessary. And if the frame is already a foreground frame, raising it isn't necessary. So instead I introduced a new message, WM_EMACS_BRINGTOTOP, and used that in raise-frame. The diffs are below (installed as revision 108409 on the trunk). Thanks. I'm closing this bug report. === modified file 'src/ChangeLog' --- src/ChangeLog 2012-05-28 07:13:45 +0000 +++ src/ChangeLog 2012-05-28 17:22:40 +0000 @@ -1,3 +1,17 @@ +2012-05-28 Eli Zaretskii <eliz@gnu.org> + + * w32term.c (my_bring_window_to_top): New function. + (x_raise_frame): Use handle returned by DeferWindowPos, which + could be different from the original one. Call + my_bring_window_to_top instead of my_set_foreground_window. + (Bug#11513) + + * w32fns.c (w32_wnd_proc): Accept and process WM_EMACS_BRINGTOTOP + by calling BringWindowToTop. + + * w32term.h (WM_EMACS_BRINGTOTOP): New message. + (WM_EMACS_END): Increase by one. + 2012-05-28 Paul Eggert <eggert@cs.ucla.edu> * bidi.c (bidi_mirror_char): Put eassert before conversion to int. === modified file 'src/w32fns.c' --- src/w32fns.c 2012-05-25 18:19:24 +0000 +++ src/w32fns.c 2012-05-28 17:22:40 +0000 @@ -3663,6 +3663,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA case WM_EMACS_SHOWWINDOW: return ShowWindow ((HWND) wParam, (WPARAM) lParam); + case WM_EMACS_BRINGTOTOP: case WM_EMACS_SETFOREGROUND: { HWND foreground_window; @@ -3680,6 +3681,8 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA foreground_thread = 0; retval = SetForegroundWindow ((HWND) wParam); + if (msg == WM_EMACS_BRINGTOTOP) + retval = BringWindowToTop ((HWND) wParam); /* Detach from the previous foreground thread. */ if (foreground_thread) === modified file 'src/w32term.c' --- src/w32term.c 2012-05-18 08:36:50 +0000 +++ src/w32term.c 2012-05-28 17:22:40 +0000 @@ -3492,6 +3492,12 @@ my_destroy_window (struct frame * f, HWN (WPARAM) hwnd, 0); } +static void +my_bring_window_to_top (HWND hwnd) +{ + SendMessage (hwnd, WM_EMACS_BRINGTOTOP, (WPARAM) hwnd, 0); +} + /* Create a scroll bar and return the scroll bar vector for it. W is the Emacs window on which to create the scroll bar. TOP, LEFT, WIDTH and HEIGHT are the pixel coordinates and dimensions of the @@ -5600,24 +5606,27 @@ x_raise_frame (struct frame *f) HDWP handle = BeginDeferWindowPos (2); if (handle) { - DeferWindowPos (handle, - FRAME_W32_WINDOW (f), - HWND_TOP, - 0, 0, 0, 0, - SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE); - - DeferWindowPos (handle, - GetForegroundWindow (), - FRAME_W32_WINDOW (f), - 0, 0, 0, 0, - SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE); - - EndDeferWindowPos (handle); + handle = DeferWindowPos (handle, + FRAME_W32_WINDOW (f), + HWND_TOP, + 0, 0, 0, 0, + SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE); + if (handle) + { + handle = DeferWindowPos (handle, + GetForegroundWindow (), + FRAME_W32_WINDOW (f), + 0, 0, 0, 0, + SWP_NOSIZE | SWP_NOMOVE | + SWP_NOACTIVATE); + if (handle) + EndDeferWindowPos (handle); + } } } else { - my_set_foreground_window (FRAME_W32_WINDOW (f)); + my_bring_window_to_top (FRAME_W32_WINDOW (f)); } UNBLOCK_INPUT; === modified file 'src/w32term.h' --- src/w32term.h 2012-01-19 07:21:25 +0000 +++ src/w32term.h 2012-05-28 17:22:40 +0000 @@ -576,7 +576,8 @@ do { \ #define WM_EMACS_HIDE_CARET (WM_EMACS_START + 18) #define WM_EMACS_SETCURSOR (WM_EMACS_START + 19) #define WM_EMACS_PAINT (WM_EMACS_START + 20) -#define WM_EMACS_END (WM_EMACS_START + 21) +#define WM_EMACS_BRINGTOTOP (WM_EMACS_START + 21) +#define WM_EMACS_END (WM_EMACS_START + 22) #define WND_FONTWIDTH_INDEX (0) #define WND_LINEHEIGHT_INDEX (4) ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-05-28 17:28 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-05-18 21:06 bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows Kazuhiro Ito 2012-05-19 8:02 ` Eli Zaretskii 2012-05-19 12:02 ` Kazuhiro Ito 2012-05-19 12:42 ` Eli Zaretskii 2012-05-19 12:56 ` martin rudalics 2012-05-19 13:47 ` Eli Zaretskii 2012-05-21 19:12 ` Eli Zaretskii 2012-05-23 10:48 ` Kazuhiro Ito 2012-05-23 16:20 ` Eli Zaretskii 2012-05-23 16:38 ` Drew Adams 2012-05-24 6:04 ` Kazuhiro Ito 2012-05-24 16:01 ` Lennart Borgman 2012-05-28 17:28 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).