Tk Source Code

Ticket Change Details
Login
Overview

Artifact ID: e3035b4d80b572ac1081099ee5a1cc2b472a049b963b618d60abc00b02f28ce9
Ticket: 22349fc78a7354435595369924179e8fabafb484
Incorrect crossing events upon destruction of the pointer window under MS Windows
User & Date: erikleunissen 2024-04-10 14:41:11
Changes

  1. icomment:
    Since the tests for this ticket were integrated into the Tk test suite,
    I didn't have a close look to them. (That's merely because my drive to do so
    is inversely proportional to my confidence that you did this accurately,
    François.) Well, I did that now, and everything looks fine to me, except for the
    following two aspects where I have a small doubt/question:
    
    A. Regarding this line:
    
            [https://core.tcl-lang.org/tk/file?ci=e3db006d1160463e&name=tests/event.test&ln=913]
        
        In my original test script the code reads:
        
            tkwait visibility .
            update; # service remaining screen drawing events (e.g. <Expose>)
    
        Now it is:
    
            _pause 200; # service remaining screen drawing events (e.g. <Expose>)
    
        a. Was the removal of the call to "tkwait visibility" on purpose? It makes that
           we can't be sure that the window is visible, e.g. if the end user's system
           is very busy processing other stuff during the 200 ms that the Tk process
           is waiting). This makes me uncomfortable.
        b. If the removal of the call to "tkwait visibility" was on purpose, then
           the comment is somewhat misleading, especially the word "remaining".
           What's happening during the [_pause 200] is much more than just the
           servicing of "remaining" drawing events. A better comment would be:
       
              _pause 200; # let the drawing of the window to the screen occur to its completion
    
           (or something equivalent).
    
    B. Regarding the 200 ms that _pause is waiting:
       It didn't go unnoticed that 200 ms is less than the current value for MOUSE_TIMER_INTERVAL
       (250 ms). The choice makes that there is no time for the sequence MouseTimerProc() -> Tk_PointerEvent()
       to be run twice. (This is on MS Windows, I don't know if this also holds for macOS/aqua).
       
       Was this consideration indeed the reason for choosing 200 ms? If so, wouldn't it wise to
       add this as an explanation somewhere?
    
  2. login: "erikleunissen"
  3. mimetype: "text/x-fossil-plain"