Thread from comp.lang.tcl (4 replies)

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

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.

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

Helmut Giese <hgiese@ratiosoft.com> wrote:
> 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 <hgiese@ratiosoft.com> wrote:
>> 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'.

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