Re: Curious event behaviour

Helmut Giese <hgiese@ratiosoft.com> wrote:

Hello out there,
take the following script:
        ---

[see prior post for script]

        ---
It programs two events which are to be executed either "inline" in the
script (evInScript == 1) or scheduled for some time after.
This is the result:
        ---
In the second case the events never happened (or they happened but
were not recognized, which amounts to the same). I consider this a
bug. Should I submit a ticket?

It is a bug, but not a bug in Tk.  It is a bug in your code.

I made the following initial changes to test on linux:

    --- hg~ 2024-08-31 10:13:57.860784063 -0400
    +++ hg 2024-08-31 10:12:26.551823871 -0400
    @@ -1,9 +1,10 @@
    +#!/usr/bin/wish
     package require Tk
     foreach ch [winfo children "."] {destroy $ch}
    
     # This variable controls whether the events happen during the script's
     # execution or are scheduled for some time after
    -set evInScript 0
    +set evInScript [lindex $argv 0]
    
     set c [canvas .c -width 400 -height 300 -bd 0 -bg lightyellow]
     pack $c

Launch in 'wish' and take the initial value from evInScript from the
command line instead of hard coding.  Got the exact same results you
do.

Why?

Because Tk is mostly lazy evaluation, meaning when you call commands
such as [canvas] or [$c create] or "$c bind ..." some portion (if not
most) of request you are making is not executed right then and there. 
Much of the work is deferred, by queueing it onto the event loop, and
waiting for your script to finish its 'work' and only then do the event
loop work items get executed.

In the "0" case you queue your two generates as events to happen
'later' (1 second and 2 seconds later) and then your script reaches
its end.  That lets the event loop queue drain, and the canvas, the two
rectangles, and the bindings get created.  So that when the 1 second
later event generate occurs, there is alrealy a fully initialized
canvas, with two rectangles on it, and two bindings on the rectangles.

In the "1" case, you don't do the above.  You wait, in your script,
synchronously, for 1 second, never letting the event queue drain, then
you trigger an 'event' on the canvas, but the canvas is not fully
initiaized yet, so the event just 'occurs' with nothing there to
respond to it.  Same with the next 2 second wait, synchronous, then an
event to an only 'half-ready' rectangle.  This is why you see nothing
for the "1" case, you never let the canvas fully initialize until after
you tried poking it with the two events.

Making this additional change:

    --- hg~ 2024-08-31 10:16:44.904805513 -0400
    +++ hg 2024-08-31 10:12:26.551823871 -0400
    @@ -15,6 +15,7 @@
         $c bind $id <Button-1> [list puts "<Button-1> for id $id"]
         $c bind $id <Shift-Button-1> [list puts "<Shift-Button-1> for id $id"]
     }
    +update idletasks
     if {$evInScript} {
         after 1000
         event generate $c <Button-1> -x 150 -y 150

Fixes the "1" case so that both output the same output, just in
different orders:

    $ ./hg 0
    Done for evInScript == 0
    <Button-1> for id 1
    <Shift-Button-1> for id 2
    ^C
    $ ./hg 1
    <Button-1> for id 1
    <Shift-Button-1> for id 2
    Done for evInScript == 1
    ^C

That [update idletasks] drains all the queued Tk "setup" tasks for the
canvas, resulting in it now being fully initialized and ready to listen
to and respond to events.