> Cc: "Drew Adams" <[EMAIL PROTECTED]>, [email protected]
> From: Jason Rumney <[EMAIL PROTECTED]>
> Date: Sat, 08 Apr 2006 09:51:13 +0100
>
> More likely the mouse move messages when we are over a menu do not
> correspond to any frame, and instead of discarding them, we use the
> same x/y coordinates in the default frame and go through all the
> mouse highlight and pointer code (though that does not explain why
> this does not happen with a single frame).
I think you are right. Does the change below look good? It fixes the
problem for me.
Index: src/w32fns.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v
retrieving revision 1.267
diff -u -p -r1.267 w32fns.c
--- src/w32fns.c 8 Apr 2006 12:26:25 -0000 1.267
+++ src/w32fns.c 8 Apr 2006 12:57:27 -0000
@@ -3297,6 +3297,14 @@ w32_wnd_proc (hwnd, msg, wParam, lParam)
return (msg == WM_XBUTTONDOWN || msg == WM_XBUTTONUP);
case WM_MOUSEMOVE:
+ /* Ignore mouse movements as long as the menu is active. These
+ movements are processed by the window manager anyway, and
+ it's wrong to handle them as if they happened on the
+ underlying frame. */
+ f = x_window_to_frame (dpyinfo, hwnd);
+ if (f && f->output_data.w32->menubar_active)
+ return 0;
+
/* If the mouse has just moved into the frame, start tracking
it, so we will be notified when it leaves the frame. Mouse
tracking only works under W98 and NT4 and later. On earlier
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
