Tk Source Code

This problem occurs under Windows XP and MacOS 10.5 when using ActiveTcl 8.5.2. It also occurs on both those OS using various TclTk 8.4.x. It does not occur under Linux.

Normally if you doubleclick, you get a <Button-1>, <ButtonRelease-1> and <Double-1> event in that order. However, if processing one of the first two takes more than a certain time, the Double event will not be generated at all. 

This code snippet illustrates the problem; the loop count of 1e7 is right for my 2GHz core 2 duo MacBook. Interestingly if you divide this delay between the click and release events, the double is generated! But put it all on the release, and it is not. 
======
proc delay {n} {
    for {set z 0} {$z < $n} {incr z} {}
}

pack [canvas .c]
.c config -bg beige
bind .c <Button-1> {delay 10000000; .c config -bg green}
bind .c <ButtonRelease-1> {delay 0; .c config -bg yellow}
bind .c <Double-1> {.c config -bg red; puts double}
======

Backported to 8.6 in [1f958e6c4d].

Fixed [2535a940feb929dd|here] and in core-9-0-branch

Feel free to backport this to 8.6, if you want.

Reproduced on Windows 11 with 8.6.18 and 9.1 by injecting two clicks 50 ms apart: with a fast <ButtonRelease-1> handler the events are "press release Double release", with a handler which blocks for 600 ms the Double event is not generated. On X11 it is generated in both cases, as the reporter noticed.

The cause is that on Windows the time of a mouse or key event is taken when the message is processed (GetTickCount()), not when it was posted, so the events of the second click get times which are later than the real ones by the duration of the handler, and tkBind.c does not see them within the 500 ms of the first click. On X11 the events carry the timestamp of the X server, which the handler cannot influence.

Fixed in [6498c68552] (branch win-event-time): a new TkpGetEventTime() returns GetMessageTime(), the time at which the message being processed was posted; the same time base as before. Verified: with the fix the Double event is generated with handler delays of 600 ms and 1500 ms.

On macOS the hook returns the current time, as before; the analogous fix there would be to use the timestamp of the NSEvent.