Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <vav97k$11d4l$2@dont-email.me>
Deutsch   English   Français   Italiano  
<vav97k$11d4l$2@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Rich <rich@example.invalid>
Newsgroups: comp.lang.tcl
Subject: Re: Curious event behaviour
Date: Sat, 31 Aug 2024 14:27:01 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 92
Message-ID: <vav97k$11d4l$2@dont-email.me>
References: <v176dj9u5vmca0l5cc320f2ph8dd8tnmne@4ax.com>
Injection-Date: Sat, 31 Aug 2024 16:27:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2f31ca9108b7a3035762c515d9ff524f";
	logging-data="1094805"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18hR6k2yCKIwjlxCpY6BA1r"
User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
Cancel-Lock: sha1:i2uKj2Ar4pMUs1s36zPpcTkDkJE=
Bytes: 4425

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.