event generate options, virtual events and client data 
Author Message
 event generate options, virtual events and client data

I need advice from someone who understands the internal workings of virtual
events and the event generate command....

One of the things that really bugs me [1] about tk events is that they
aren't first class objects at the script level, and there's no way to
associate application-specific data to a virtual event. The result is,
events aren't too handy as a general message-passing mechanism, though I'm
often tempted to think they are in spite of evidence to the contrary.

The man page for "event generate" suggests it is possible to supply a -time
argument, an integer, which corresponds to the %t binding substitution.
However, the man page also says -time is "Valid for KeyPress, KeyRelease,
ButtonPress, ButtonRelease, Enter, Leave, Motion, and Property events".
There's no mention of virtual events.

So, I'm thinking I could use -t to specify a unique integer for my virtual
event, and store additional event data in a global array indexed by -- you
guessed it -- this unique number.

So, for example, I might generate an event like this:

    set id [clock clicks]
    set ::eventData($id,FOO) "yellow"
    set ::eventData($id,BAR) "banana"
    event generate <<MyUniqueEvent>> -time $id

I could bind to it thusly:

    bind . <<MyUniqueEvent>> [list handleUniqueEvent %t]

... and handle it like so:

    proc handleUniqueEvent {id} {
        puts "the FOO field from the event is $::eventData($id,FOO)"
        puts "the BAR field from the event is $::eventData($id,BAR)"
    }

The question I have is this: Is this kosher? Since the man page seems to
omit any mention of virtual events WRT event generate, or exactly what is
meant by "valid for...", it's not clear whether I'm being clever or just
asking for trouble. [2]

Put another way, will anything bad happen if I use -time for a virtual event
even though the man page doesn't say in so many words that I can? And if I
do use the -time field, does it really need to be some sort of valid time
value, or can it be any random integer? I only have a windows box to test
this on, and it seems to work. But my paranoid evil twin is afraid this
might not work as well on unix or on a Macintosh.

[1] Obviously it doesn't bug me enough to motivate me to fix it in the core,
but it may have motivated me to find a tcl-only solution :-)
[2] Experience has taught me that when I think I'm being clever, I'm usually
not.

--
Bryan Oakley



Sat, 14 Aug 2004 14:45:03 GMT  
 event generate options, virtual events and client data

Quote:

> I need advice from someone who understands the internal workings of virtual
> events and the event generate command....
> One of the things that really bugs me [1] about tk events is that they
> aren't first class objects at the script level, and there's no way to
> associate application-specific data to a virtual event. The result is,
> events aren't too handy as a general message-passing mechanism, though I'm
> often tempted to think they are in spite of evidence to the contrary.
> The man page for "event generate" suggests it is possible to supply a -time
> argument, an integer, which corresponds to the %t binding substitution.
> However, the man page also says -time is "Valid for KeyPress, KeyRelease,
> ButtonPress, ButtonRelease, Enter, Leave, Motion, and Property events".
> There's no mention of virtual events.
> So, I'm thinking I could use -t to specify a unique integer for my virtual
> event, and store additional event data in a global array indexed by -- you
> guessed it -- this unique number.
> So, for example, I might generate an event like this:
>     set id [clock clicks]
>     set ::eventData($id,FOO) "yellow"
>     set ::eventData($id,BAR) "banana"
>     event generate <<MyUniqueEvent>> -time $id
> I could bind to it thusly:
>     bind . <<MyUniqueEvent>> [list handleUniqueEvent %t]
> ... and handle it like so:
>     proc handleUniqueEvent {id} {
>         puts "the FOO field from the event is $::eventData($id,FOO)"
>         puts "the BAR field from the event is $::eventData($id,BAR)"
>     }
> The question I have is this: Is this kosher? Since the man page seems to
> omit any mention of virtual events WRT event generate, or exactly what is
> meant by "valid for...", it's not clear whether I'm being clever or just
> asking for trouble. [2]
> Put another way, will anything bad happen if I use -time for a virtual event
> even though the man page doesn't say in so many words that I can? And if I
> do use the -time field, does it really need to be some sort of valid time
> value, or can it be any random integer? I only have a windows box to test
> this on, and it seems to work. But my paranoid evil twin is afraid this
> might not work as well on unix or on a Macintosh.
> [1] Obviously it doesn't bug me enough to motivate me to fix it in the core,
> but it may have motivated me to find a tcl-only solution :-)
> [2] Experience has taught me that when I think I'm being clever, I'm usually
> not.

Well, my Tcl is rather rusty, but if this code demonstrates the problem, I'm
sorry to say it doesn't work under Unix:

#!/usr/local/bin/wish8.4

proc bgerror {msg} {
    puts bgerror=$msg

Quote:
}

proc handleUniqueEvent {id} {
    puts fetchid=$id
    puts "the FOO field from the event is $::eventData($id,FOO)"
    puts "the BAR field from the event is $::eventData($id,BAR)"

Quote:
}

event add <<MyUniqueEvent>> <ButtonPress-1>

bind . <<MyUniqueEvent>> [list handleUniqueEvent %t]

set id [clock clicks]
puts storeid=$id
set ::eventData($id,FOO) "yellow"
set ::eventData($id,BAR) "banana"

event generate . <<MyUniqueEvent>> -time $id

label .b -text Hi
pack .b

Which produces this result:

Pandora:/home/lusol/lusol/sgi/tcl/./evgen.tcl
storeid=1994389389
fetchid=79276471
bgerror=can't read "::eventData(79276471,FOO)": no such element in array

Assuming I haven't made a stupid mistake, similar code doesn't work in
Perl/Tk either.  But, if, in the bind() callback, instead of passing %t,
you could arrange to pass a deferred evaluation of $id, you can do
what you want.  In Perl/Tk I'd use a reference, and dereference it in
the callback.  So this works:

#!/usr/local/bin/perl
use Tk;

sub handleUniqueEvent {

    $id = $$id_ref;
    print "fetchid=$id\n";
    print "the FOO field from the event is $eventData{$id,FOO}\n";
    print "the BAR field from the event is $eventData{$id,BAR}\n";

Quote:
}

$mw = MainWindow->new;

$mw->eventAdd('<<MyUniqueEvent>>' => '<ButtonPress-1>');

$mw->bind('<<MyUniqueEvent>>' => [\&handleUniqueEvent, \$id]);

$id = time;
print "storeid=$id\n";
$eventData{$id,FOO} =  "yellow";
$eventData{$id,BAR} =  "banana";

$mw->eventGenerate('<<MyUniqueEvent>>');

$mw->Label(-text => 'Hi')->pack;

MainLoop;

Producing:

Pandora:/home/lusol/lusol/sgi/tcl/./evgen    
storeid=1014736477
fetchid=1014736477
the FOO field from the event is yellow
the BAR field from the event is banana

But my Tcl to not up to{*filter*}anymore ...

Steve

'other perl hacker';$z='createText';$c=$m->Canvas(-wi,$_[1],-he,25)->grid;$c->$
En'.
'ter>',sub{$y=int(rand($m->screenheight));$m->geometry("+$y+$y")});MainLoop;



Sat, 14 Aug 2004 23:17:46 GMT  
 event generate options, virtual events and client data

Quote:
> Pandora:/home/lusol/lusol/sgi/tcl/./evgen.tcl
> storeid=1994389389
> fetchid=79276471

Hmmm. You may have confirmed my suspicions. It appears that, at least on
your system, the event binding gets a different time value than the one
given to the event generate command. That's disappointing, and a bit
unexpected. In fact, I'd go so far as to say it's a bug in tk, since the
event man page says that if you don't specify a value for a field it gets
initialized to zero. It's reasonable to infer that if you *do* set a value,
it remains as the value set.

What OS did you run the above test on? I assume some flavor of unix...



Sun, 15 Aug 2004 00:20:03 GMT  
 event generate options, virtual events and client data


Quote:

> > I need advice from someone who understands the internal workings of virtual
> > events and the event generate command....

> > One of the things that really bugs me [1] about tk events is that they
> > aren't first class objects at the script level, and there's no way to
> > associate application-specific data to a virtual event. The result is,
> > events aren't too handy as a general message-passing mechanism, though I'm
> > often tempted to think they are in spite of evidence to the contrary.

> > The man page for "event generate" suggests it is possible to supply a -time
> > argument, an integer, which corresponds to the %t binding substitution.
> > However, the man page also says -time is "Valid for KeyPress, KeyRelease,
> > ButtonPress, ButtonRelease, Enter, Leave, Motion, and Property events".
> > There's no mention of virtual events.

> > So, I'm thinking I could use -t to specify a unique integer for my virtual
> > event, and store additional event data in a global array indexed by -- you
> > guessed it -- this unique number.

> > So, for example, I might generate an event like this:

> >     set id [clock clicks]
> >     set ::eventData($id,FOO) "yellow"
> >     set ::eventData($id,BAR) "banana"
> >     event generate <<MyUniqueEvent>> -time $id

> > I could bind to it thusly:

> >     bind . <<MyUniqueEvent>> [list handleUniqueEvent %t]

> > ... and handle it like so:

> >     proc handleUniqueEvent {id} {
> >         puts "the FOO field from the event is $::eventData($id,FOO)"
> >         puts "the BAR field from the event is $::eventData($id,BAR)"
> >     }

> > The question I have is this: Is this kosher? Since the man page seems to
> > omit any mention of virtual events WRT event generate, or exactly what is
> > meant by "valid for...", it's not clear whether I'm being clever or just
> > asking for trouble. [2]

> > Put another way, will anything bad happen if I use -time for a virtual event
> > even though the man page doesn't say in so many words that I can? And if I
> > do use the -time field, does it really need to be some sort of valid time
> > value, or can it be any random integer? I only have a windows box to test
> > this on, and it seems to work. But my paranoid evil twin is afraid this
> > might not work as well on unix or on a Macintosh.

> > [1] Obviously it doesn't bug me enough to motivate me to fix it in the core,
> > but it may have motivated me to find a tcl-only solution :-)
> > [2] Experience has taught me that when I think I'm being clever, I'm usually
> > not.

> Well, my Tcl is rather rusty, but if this code demonstrates the problem, I'm
> sorry to say it doesn't work under Unix:

> #!/usr/local/bin/wish8.4

> proc bgerror {msg} {
>     puts bgerror=$msg
> }

> proc handleUniqueEvent {id} {
>     puts fetchid=$id
>     puts "the FOO field from the event is $::eventData($id,FOO)"
>     puts "the BAR field from the event is $::eventData($id,BAR)"
> }

> event add <<MyUniqueEvent>> <ButtonPress-1>

> bind . <<MyUniqueEvent>> [list handleUniqueEvent %t]

> set id [clock clicks]
> puts storeid=$id
> set ::eventData($id,FOO) "yellow"
> set ::eventData($id,BAR) "banana"

> event generate . <<MyUniqueEvent>> -time $id

> label .b -text Hi
> pack .b

> Which produces this result:

> Pandora:/home/lusol/lusol/sgi/tcl/./evgen.tcl
> storeid=1994389389
> fetchid=79276471
> bgerror=can't read "::eventData(79276471,FOO)": no such element in array

FYI,

That code (under 8.2.1 on Tru64 Unix, and 8.3.4 on Win2K) seems to work fine for me

Bruce



Sun, 15 Aug 2004 01:02:58 GMT  
 event generate options, virtual events and client data

Quote:



>> > I need advice from someone who understands the internal workings of virtual
>> > events and the event generate command....
>> #!/usr/local/bin/wish8.4

>> proc bgerror {msg} {
>>     puts bgerror=$msg
>> }

>> proc handleUniqueEvent {id} {
>>     puts fetchid=$id
>>     puts "the FOO field from the event is $::eventData($id,FOO)"
>>     puts "the BAR field from the event is $::eventData($id,BAR)"
>> }

>> event add <<MyUniqueEvent>> <ButtonPress-1>

>> bind . <<MyUniqueEvent>> [list handleUniqueEvent %t]

>> set id [clock clicks]
>> puts storeid=$id
>> set ::eventData($id,FOO) "yellow"
>> set ::eventData($id,BAR) "banana"

>> event generate . <<MyUniqueEvent>> -time $id

>> label .b -text Hi
>> pack .b

>> Which produces this result:

>> Pandora:/home/lusol/lusol/sgi/tcl/./evgen.tcl
>> storeid=1994389389
>> fetchid=79276471
>> bgerror=can't read "::eventData(79276471,FOO)": no such element in array

> FYI,
> That code (under 8.2.1 on Tru64 Unix, and 8.3.4 on Win2K) seems to work fine for me

My testing was on IRIX and Redhat Linux (7.0), both of which failed.  So,
it seems that, in general, this is not a safe trick.  Does my workaround
offer hope?

Steve



Sun, 15 Aug 2004 01:39:06 GMT  
 event generate options, virtual events and client data

Quote:
> My testing was on IRIX and Redhat Linux (7.0), both of which failed.  So,
> it seems that, in general, this is not a safe trick.  Does my workaround
> offer hope?

What version of tcl were you using?

I'm not interested in the workaround. I know I can use a global variable,
but the problem I'm trying to solve is how to associate a unique number with
an event, not so much how to access a global array in an event handler.
There's a subtle difference.

What I'm trying to protect against is an event handler that itself generates
an event. Using a single global variable won't work since subsequent events
will override the current global value. Of course, I could implement some
sort of stack, pushing and popping values when I process events, but that's
imperfect also.

The real solution is to be able to associate a unique, application-defined
number with an event.

I'm curious if, on platforms where the -time option doesn't work as
advertised, if using the -serial option to event generate, with %# as the
substitution, would work any better. The description of %# is a bit vague.
It says it is "The number of the last client request processed by the server
(the serial field from the event).  Valid for all event types. ".. but the
definition of "client" and "server" is unclear. I assume it is meant in the
context of X windows, and assumes a knowledge of X events, but I can't be
sure. And it's not clear what will happen, if anything, if I define my own
serial number.I've pretty much forgotten everything I ever knew about the
inner mysteries of X.

IMO, the ultimate right way to sove this is by introducing a new option to
event generate (for example, -data, or -string, or something similar) and a
new binding substitution (eg: %$, perhaps). If we could associate arbitrary
strings in this manner, it would be awesome. We could stick to plain
integers and have -id/%i, which would undoubtedly be easy to implement and
almost as powerful, since the id could be used as an index into a private
array. Being able to pass actual data with the event would be better,
assuming it would be GC'd once the event has run the entire binding
gauntlet.

*sigh* I really need to install a C compiler and get my hands dirty in the
source. In this case, I'd suspect the effort to do so would greatly outweigh
the time it would take to add this small feature.

In the mean time, I'm just looking for a pure-tcl solution that still lets
me assign a unique value to an event.



Sun, 15 Aug 2004 03:03:41 GMT  
 event generate options, virtual events and client data

Quote:

> I'm curious if, on platforms where the -time option doesn't work as
> advertised, if using the -serial option to event generate, with %# as the
> substitution, would work any better. The description of %# is a bit vague.
> It says it is "The number of the last client request processed by the server
> (the serial field from the event).  Valid for all event types. ".. but the
> definition of "client" and "server" is unclear. I assume it is meant in the
> context of X windows, and assumes a knowledge of X events, but I can't be
> sure. And it's not clear what will happen, if anything, if I define my own
> serial number.I've pretty much forgotten everything I ever knew about the
> inner mysteries of X.

The [bind] manpage really assumes a deep knowledge of X, and there are many of
its mysteries that I am still a long way from penetrating (all the Focus related
stuff is particularly gnostic...)  Documentation improvements (particularly ones
that state when an event might be generated by the system) would be gladly
accepted...

Quote:
> IMO, the ultimate right way to sove this is by introducing a new option to
> event generate (for example, -data, or -string, or something similar) and a
> new binding substitution (eg: %$, perhaps). If we could associate arbitrary
> strings in this manner, it would be awesome. We could stick to plain
> integers and have -id/%i, which would undoubtedly be easy to implement and
> almost as powerful, since the id could be used as an index into a private
> array. Being able to pass actual data with the event would be better,
> assuming it would be GC'd once the event has run the entire binding
> gauntlet.

I've wanted that for a long time.  Maybe longer.  Go for it!

Donal.
--

-- With a complex beast like Swing, it's not just a matter of "What button
   should I push", but rather "How do I put myself into a nice metamorphosis
   so that I am deemed acceptable by the Swing Gods."             -- Anonymous



Sun, 15 Aug 2004 17:27:02 GMT  
 event generate options, virtual events and client data

Quote:

>> My testing was on IRIX and Redhat Linux (7.0), both of which failed.  So,
>> it seems that, in general, this is not a safe trick.  Does my workaround
>> offer hope?
> What version of tcl were you using?

8.4a3

Quote:
> I'm not interested in the workaround. I know I can use a global variable,
> but the problem I'm trying to solve is how to associate a unique number with
> an event, not so much how to access a global array in an event handler.
> There's a subtle difference.
> What I'm trying to protect against is an event handler that itself generates
> an event. Using a single global variable won't work since subsequent events
> will override the current global value. Of course, I could implement some
> sort of stack, pushing and popping values when I process events, but that's
> imperfect also.

Ah, the real problem (-:, I'd use a closure in Perl/Tk.

Quote:
> The real solution is to be able to associate a unique, application-defined
> number with an event.
> I'm curious if, on platforms where the -time option doesn't work as
> advertised, if using the -serial option to event generate, with %# as the
> substitution, would work any better. The description of %# is a bit vague.
> It says it is "The number of the last client request processed by the server
> (the serial field from the event).  Valid for all event types. ".. but the
> definition of "client" and "server" is unclear. I assume it is meant in the
> context of X windows, and assumes a knowledge of X events, but I can't be
> sure. And it's not clear what will happen, if anything, if I define my own
> serial number.I've pretty much forgotten everything I ever knew about the
> inner mysteries of X.
> IMO, the ultimate right way to sove this is by introducing a new option to
> event generate (for example, -data, or -string, or something similar) and a
> new binding substitution (eg: %$, perhaps). If we could associate arbitrary
> strings in this manner, it would be awesome. We could stick to plain
> integers and have -id/%i, which would undoubtedly be easy to implement and
> almost as powerful, since the id could be used as an index into a private
> array. Being able to pass actual data with the event would be better,
> assuming it would be GC'd once the event has run the entire binding
> gauntlet.

Yes, that's a great idea.

Quote:
> *sigh* I really need to install a C compiler and get my hands dirty in the
> source. In this case, I'd suspect the effort to do so would greatly outweigh
> the time it would take to add this small feature.
> In the mean time, I'm just looking for a pure-tcl solution that still lets
> me assign a unique value to an event.

A Tcler needs to speak up then, sorry I don't have a better solution.

Steve

'other perl hacker';$z='createText';$c=$m->Canvas(-wi,$_[1],-he,25)->grid;$c->$
En'.
'ter>',sub{$y=int(rand($m->screenheight));$m->geometry("+$y+$y")});MainLoop;



Sun, 15 Aug 2004 21:58:37 GMT  
 event generate options, virtual events and client data
The "generate" command with "-time" attribute seems to work (on Linux
wish8.3) as Bryan had intended.  Spurious interaction with
uninstantiated window may be the culprit.  Corrected code at end of
post.


Quote:

> > I need advice from someone who understands the internal workings of virtual
> > events and the event generate command....

> > One of the things that really bugs me [1] about tk events is that they
> > aren't first class objects at the script level, and there's no way to
> > associate application-specific data to a virtual event. The result is,
> > events aren't too handy as a general message-passing mechanism, though I'm
> > often tempted to think they are in spite of evidence to the contrary.

> > The man page for "event generate" suggests it is possible to supply a -time
> > argument, an integer, which corresponds to the %t binding substitution.
> > However, the man page also says -time is "Valid for KeyPress, KeyRelease,
> > ButtonPress, ButtonRelease, Enter, Leave, Motion, and Property events".
> > There's no mention of virtual events.

> > So, I'm thinking I could use -t to specify a unique integer for my virtual
> > event, and store additional event data in a global array indexed by -- you
> > guessed it -- this unique number.

> > So, for example, I might generate an event like this:

> >     set id [clock clicks]
> >     set ::eventData($id,FOO) "yellow"
> >     set ::eventData($id,BAR) "banana"
> >     event generate <<MyUniqueEvent>> -time $id

> > I could bind to it thusly:

> >     bind . <<MyUniqueEvent>> [list handleUniqueEvent %t]

> > ... and handle it like so:

> >     proc handleUniqueEvent {id} {
> >         puts "the FOO field from the event is $::eventData($id,FOO)"
> >         puts "the BAR field from the event is $::eventData($id,BAR)"
> >     }

> > The question I have is this: Is this kosher? Since the man page seems to
> > omit any mention of virtual events WRT event generate, or exactly what is
> > meant by "valid for...", it's not clear whether I'm being clever or just
> > asking for trouble. [2]

> > Put another way, will anything bad happen if I use -time for a virtual event
> > even though the man page doesn't say in so many words that I can? And if I
> > do use the -time field, does it really need to be some sort of valid time
> > value, or can it be any random integer? I only have a windows box to test
> > this on, and it seems to work. But my paranoid evil twin is afraid this
> > might not work as well on unix or on a Macintosh.

> > [1] Obviously it doesn't bug me enough to motivate me to fix it in the core,
> > but it may have motivated me to find a tcl-only solution :-)
> > [2] Experience has taught me that when I think I'm being clever, I'm usually
> > not.

> Well, my Tcl is rather rusty, but if this code demonstrates the problem, I'm
> sorry to say it doesn't work under Unix:

> #!/usr/local/bin/wish8.4

> proc bgerror {msg} {
>     puts bgerror=$msg
> }

> proc handleUniqueEvent {id} {
>     puts fetchid=$id
>     puts "the FOO field from the event is $::eventData($id,FOO)"
>     puts "the BAR field from the event is $::eventData($id,BAR)"
> }

> event add <<MyUniqueEvent>> <ButtonPress-1>

> bind . <<MyUniqueEvent>> [list handleUniqueEvent %t]

> set id [clock clicks]
> puts storeid=$id
> set ::eventData($id,FOO) "yellow"
> set ::eventData($id,BAR) "banana"

> event generate . <<MyUniqueEvent>> -time $id

> label .b -text Hi
> pack .b

> Which produces this result:

> Pandora:/home/lusol/lusol/sgi/tcl/./evgen.tcl
> storeid=1994389389
> fetchid=79276471
> bgerror=can't read "::eventData(79276471,FOO)": no such element in array

... Perl Stuff Deleted ...

Quote:
> Steve

I tried the Tcl that you had posted, Steve, and you are right.  It
don't work.
However, since there is a race condition in that you generate the
event associated with '.' before '.' is on the screen, it isn't
reliable.  So, you
are right.

By delaying the generation of the event with an " after 1000 "
command, the
event gets generated and handled quite nicely.

#!/usr/local/bin/wish8.4

#proc bgerror {msg} {
#           puts bgerror=$msg
#    }

proc handleUniqueEvent {id} {
        puts fetchid=$id
        puts "the FOO field from the event is $::eventData($id,FOO)"
        puts "the BAR field from the event is $::eventData($id,BAR)"
        }

event add <<MyUniqueEvent>> <ButtonPress-1>

bind .  <<MyUniqueEvent>> [list handleUniqueEvent %t]

set id [clock clicks]
puts storeid=$id
set ::eventData($id,FOO) "yellow"
set ::eventData($id,BAR) "banana"

label .b -text Hi
pack .b

after 1000 event generate .  <<MyUniqueEvent>> -time $id

vwait xxx



Mon, 16 Aug 2004 15:45:20 GMT  
 event generate options, virtual events and client data

Quote:
> The "generate" command with "-time" attribute seems to work (on Linux
> wish8.3) as Bryan had intended.  Spurious interaction with
> uninstantiated window may be the culprit.  Corrected code at end of
> post.

From what I gather, though, this doesn't always work on all platforms. The
anecdotal evidince from this thread suggests that some unix systems change
the time value. I've also looked into using the "-serial" option, but
without a large set of unix boxes to try this on, I'm afraid I might see
similar results. :-|


Mon, 16 Aug 2004 22:04:28 GMT  
 event generate options, virtual events and client data

Quote:

> The "generate" command with "-time" attribute seems to work (on Linux
> wish8.3) as Bryan had intended.  Spurious interaction with
> uninstantiated window may be the culprit.  Corrected code at end of
> post.

It's a bit more subtle, but with your help, I know what's going on.
Thanks, I learned something new, yet again.

Quote:
> proc handleUniqueEvent {id} {
>         puts fetchid=$id
>         puts "the FOO field from the event is $::eventData($id,FOO)"
>         puts "the BAR field from the event is $::eventData($id,BAR)"
>         }
> event add <<MyUniqueEvent>> <ButtonPress-1>
> bind .  <<MyUniqueEvent>> [list handleUniqueEvent %t]
> set id [clock clicks]
> puts storeid=$id
> set ::eventData($id,FOO) "yellow"
> set ::eventData($id,BAR) "banana"
> label .b -text Hi
> pack .b
> after 1000 event generate .  <<MyUniqueEvent>> -time $id
> vwait xxx

I re-worked the code a tad:

    label .b -text Hi
    pack .b

    tkwait visibility .

    event generate .  <<MyUniqueEvent>> -time $id
    event generate .  <<MyUniqueEvent>> -time $id

There are several items of note:

. When dealing with virtual events make sure all pending events are proceesed,
  the focus is set, etc (I should know this (;). So, the wait visibility is
  important.

. The time field of a virtual event *can* be used to pass data if it's
  generated by event generate.

. The time field of a virtual event *cannot* be used to pass data if it's
  generated by a physical X11 event like a button press.  Press button 1
  over the label and note the value of the time field.  Press again and
  note the value increases. The X server is using that field.

At least on IRIX, do not know about Win32. I think.

Steve



Mon, 16 Aug 2004 22:16:00 GMT  
 event generate options, virtual events and client data

Quote:
> Well, my Tcl is rather rusty, but if this code demonstrates the problem,
I'm
> sorry to say it doesn't work under Unix:
[snip]

> Which produces this result:

> Pandora:/home/lusol/lusol/sgi/tcl/./evgen.tcl
> storeid=1994389389
> fetchid=79276471
> bgerror=can't read "::eventData(79276471,FOO)": no such element in array

I'd appreciate some clarification on this.  Your code has some extra bits in
it that make me a little unsure of exactly what you did. I'm wondering if
maybe you are reporting results after you pressed a button, rather than on
the results from the event generate command.

If you run the following code, do the two numbers match? I'd appreciate
knowing what version of tcl you used, and what platform, if it fails:

    proc myHandler {t} {puts "handler caught $t"}
    bind . <<MyEvent>> {myHandler %t}
    set id [clock clicks]
    puts "calling event generate with an id of $id"
    event generate . <<MyEvent>> -time $id

Run this in an interactive shell, or from a console where you can see what
is send to stdout.



Mon, 16 Aug 2004 22:37:46 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Q: generating virtual events with custom data

2. TIP #165: A User-Data Field for Virtual Events

3. request ability to attach and retrieve random data with generated events

4. Tcl Event Loop vs TK Event Loop issues with Asynchronous Events

5. Menus, virtual events, and "event generate" -- unhappy together?

6. Event case loses connection to data structure when data structure is modified

7. IBM To Host Virtual Conference Event

8. <<ListboxSelect>> virtual event

9. tile 0.4 combobox - virtual event

10. TIP #204: Virtual events for keyboard traversal

11. tracing all (virtual) events

12. tk_popup and virtual events

 

 
Powered by phpBB® Forum Software