Menu
▾
▴
#2004 Win32 nonclient double-click causes spurious Button-1 in app
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.
Discussion
patch on tkWinWm.c for handling WM_NC* events
Logged In: YES
user_id=241496
The patch needs more work: UpdateCursor() should not be
called on NC* events...
New patch, addressing cursor issue mentioned above.
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.