Curious event behaviour

[Helmut Giese]

Hello out there,
take the following script:
---
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 c [canvas .c -width 400 -height 300 -bd 0 -bg lightyellow]
pack $c
set id1 [$c create rectangle 100 100 200 200 -fill red]
set id2 [$c create rectangle 200 100 300 200 -fill green]

foreach id [list $id1 $id2] {
$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"]
}
if {$evInScript} {
after 1000
event generate $c <Button-1> -x 150 -y 150
after 2000
event generate $c <Shift-Button-1> -x 250 -y 150
} else {
after 1000 {event generate $c <Button-1> -x 150 -y 150}
after 2000 {event generate $c <Shift-Button-1> -x 250 -y 150}
}
puts "Done for evInScript == $evInScript"
---
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:
---
Microsoft Windows [Version 10.0.19045.4842]
(c) Microsoft Corporation. Alle Rechte vorbehalten.

d:\proj\_ToolsSE\Skeleton\TclTests>tclsh tst.tcl
Done for evInScript == 0
<Button-1> for id 1
<Shift-Button-1> for id 2

d:\proj\_ToolsSE\Skeleton\TclTests>tclsh tst.tcl
Done for evInScript == 1
---
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?

This is on Windows 10 with Tcl 8.6.10 and 8.6.13
Helmut

[Rich]

Post by Helmut Giese
Hello out there,
---

[see prior post for script]

Post by Helmut Giese
---
It programs two events which are to be executed either "inline" in the
script (evInScript == 1) or scheduled for some time after.
---
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.

[Helmut Giese]

Phew, what a relief. Many thanks Rich.
Yes, I tend to forget about 'update' and friends but now I should know
(and remember ).
Just an addendum for other Windows user: 'update idletasks' does not
suffice - I needed a fulll 'update'. 'idletasks' did result in a
change in so far a as window appeared immediatly - but it was empty.
Only with a plain 'update' appeared the complete window with the 2
rectangles immediately - and then the 2 events could fire as you
described in your exhaustive explanation.
I just read up on the documentation of 'update' and the way I
understand it is that 'update idletasks' should work - but I am no
native English speaker, so I let others decide. I only observed that
in my example it didn't.
Rich, thanks again for your help and have a nice weekend
Helmut

[Rich]

Post by Helmut Giese
I just read up on the documentation of 'update' and the way I
understand it is that 'update idletasks' should work - but I am no
native English speaker, so I let others decide. I only observed that
in my example it didn't.

It (your exact code, other than my change to make the "boolean"
settable from the CLI) worked correctly under Linux with idletasks.

So what you saw is likely some subtle difference for MSWin.

[Helmut Giese]

Post by Rich

Post by Helmut Giese
I just read up on the documentation of 'update' and the way I
understand it is that 'update idletasks' should work - but I am no
native English speaker, so I let others decide. I only observed that
in my example it didn't.

It (your exact code, other than my change to make the "boolean"
settable from the CLI) worked correctly under Linux with idletasks.

Yes, I know. That's why I wrote 'an addendum for Windows user'.

Post by Rich
So what you saw is likely some subtle difference for MSWin.

Probably