Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-1391053 ] Win32 nonclient double-click causes spurious Button-1 in app
|
From: SourceForge.net <no...@so...> - 2005-12-27 06:57:21
|
Bugs item #1391053, was opened at 2005-12-27 08:32 Message generated for change (Comment added) made by a_kovalenko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1391053&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 68. Win Window Operations Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anton Kovalenko (a_kovalenko) Assigned to: Chengye Mao (chengyemao) Summary: Win32 nonclient double-click causes spurious Button-1 in app Initial Comment: The bug is a long-standing one, so there may be duplicate reports (though I've not found them). The patch solving the problem is attached. When I maximize a Tk window by double-clicking its title bar, and the mouse cursor is then located within a Tk window (this one or another), the window under the cursor receives <Button-1>. The same thing may be observed when closing a dialog window with double-clicking its system menu button (there are traditional workarounds for it). The problem is caused by the following thing: when a non-client area of a decorative frame receives a mouse click, this event comes to WmProc() as WM_NCLBUTTONDOWN (or other WM_NC* message of this kind). Normal mouse clicks cause Tk to query the current mouse state immediately (Tk_PointerEvent()), but non-client clicks don't. So the next call to Tk_PointerEvent() will notice that the button is down, and a new event will be generated... but the windows may be already moved, maximized, closed since the real click has happened. This is exactly the case when the non-client click is to maximize or close a window. The solution (see attachment) is to call Tk_PointerEvent immediately when WM_NCLBUTTONDOWN or its counterparts are received in WmProc(). If someone decide to refactor the patch by putting the WM_NC*-related code in TranslateWinEvent(), I want him to remember that the defWindowProc _must_ be always called for these events. It's sooo easy to forget it, and forgetting it will cause a Very Bad Thing. ---------------------------------------------------------------------- >Comment By: Anton Kovalenko (a_kovalenko) Date: 2005-12-27 09:57 Message: Logged In: YES user_id=241496 Hmm.. Here is the new patch, good enough for myself but maybe too ugly. Introduces NOCURSOR_MASK flag that causes Tk_UpdatePointer not to update the cursor. Tk_UpdatePointer is now called directly from tkWinWm.c. ---------------------------------------------------------------------- Comment By: Anton Kovalenko (a_kovalenko) Date: 2005-12-27 09:20 Message: Logged In: YES user_id=241496 The patch needs more work: UpdateCursor() should not be called on NC* events... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1391053&group_id=12997 |