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.