Adding new event types to Tcl/Tk
Otto Meijer
i'm currently working on a project to add Tcl/Tk to our own software.
Because one of our windows is purely optimised for speed it's importand
that our own program has control over the event loop. Hence I use the
Tcl_DoOneEvent inside our own event loop.
Now we also have a lot of other windows that we try to get rid of
and try to implement in Tk. Our program is actually command driven
and thus something changes the state of one of these windows.
Somehow Tcl/Tk needs to know that it have to update its windows.
One way of doing this would be to create a lot of variables inside
Tcl that are linked to internal variables inside our program. Put
a trace on these and presto. However this comes at a cost.
Our own event loop has to check if one of the variables is changed
and then do and Tcl_UpdateLinkedVar. Also it creates a lot of global
variables which I really don't want.
Getting rid of the variables is easy just add new commands to
retreive the information.
However I still don't know when to update my widgets. It would be
nice if I could add a new event type and just able to bind a proc
to this event. Notifier man page gives some information how to
add a new event handler. However this seems to mee more for the case
you are implementing a new widget in C and then create your own
event handler in C.
I want the oposite, let my C program generate a Tcl/Tk event and
pref our own type.
Anybody has some idea to do this?
Otto Meijer
David Gravereaux
Hi Otto,
I messed around with a similar problem a while ago. Merging outside event
loops into Tcl's isn't easy if not wholly impossible. I gave in and ran
Tcl in a separate thread from the application to avoid it.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/tomasoft/tes/OSCON2K%2b1_TclTrack.html?rev=1.5
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway,alpha sector]
Gerald W. Lester
Take a look at the event man page.
You can bind to virtual events (events with double angle brackets, like
<<Paste>>) and also generate them. Your C code would call Tcl_Eval with
the appropriate string (e.g. "event generate ...").
Of course you have to be periodically letting the Tcl event loop run.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is
|
| Gerald...@cox.net | the man who is alive." -- Cervantes
|
+--------------------------------+---------------------------------------+
Donald Arseneau
> You can bind to virtual events (events with double angle brackets, like
> <<Paste>>) and also generate them. Your C code would call Tcl_Eval with
> the appropriate string (e.g. "event generate ...").
Something that has always (well, not always) bugged me is that
[event add <<foo>>] is illegal -- you have to associate virtual
events with at least one physical event sequence. If you want
to create an event to be used purely by [event generate <<foo>>]
you have to fond some obscure physical event to assign to it.
Donald Arseneau as...@triumf.ca
Gerald W. Lester
To use event add, yes because that is explicitly what it does --
associate a virtual event with a physical event.
But you can use virtual events that are unassoicated with any physical
event, as in:
bind . <<FooBar>> {
puts stdout {Virtual binding fired!!!}
flush stdout
}
after 1 {
event generate . <<FooBar>>
}
Try it, ya'll like it!
Donald Arseneau
> Donald Arseneau wrote:
> >
> > [event add <<foo>>] is illegal -- you have to associate virtual
> > events with at least one physical event sequence.
>
> But you can use virtual events that are unassoicated with any physical
> event, as in: bind . <<FooBar>> {
Ah Ha! I always thought the virtual events had to be "created"
first. I (obviously) never thought to try this. Thanks.
Donald Arseneau as...@triumf.ca
Bryan Oakley
I don't belive that is true. Well, it's true in the sense you have to
have a real event sequence as an argument to "event add", but you do not
need to do "event add" to use and respond to virtual events.
To wit:
button .b -text "Push me!" \
-command [list event generate . <<HelloWorld>>]
pack .b
bind . <<HelloWorld>> \
[list tk_messageBox \
-message "Received the <<HelloWorld>> event"]
I don't know if this is the designed behavior or not -- the docs are a
little vague on this matter. For example, the [event generate] command
says nothing about whether a virtual event must have been previously
defined or not, only that it can be in "any of the forms" of an event
sequence. It also states that [event generate] "arranges for it to be
processed just as if it had come from the window system" without saying
anything about whether virtual events must be first defined with [event
add]. The section named VIRTUAL EVENTS on the event man page does say
that for a binding to trigger it must have been added with "event add",
but I think that was meant only in the context of user-generated events.
So, if you can make bindings for events that don't exist and generate
events that don't exist, it seems reasonble to believe that defining an
event with [event add] is not, strictly speaking, necessary. My
experience certainly bears this one out.
Otto Meijer
Yep I sort of figured this out also by using:
Tcl_Eval( myInterp, "event generate <<MyEvents>>");
However is there a direct way to do this in C without using
the Tcl_Eval command? It seems to me this generates quite a lot
of overhead.
Otto
Jeffrey Hobbs
> Yep I sort of figured this out also by using:
> Tcl_Eval( myInterp, "event generate <<MyEvents>>");
>
> However is there a direct way to do this in C without using
> the Tcl_Eval command? It seems to me this generates quite a lot
> of overhead.
You can build up and create the events to queue directly (I'm sure
I can dig up an example), but the overhead is likely less than you
think. If you really want to cut overhead, prep the things as
objects and call Tcl_EvalObjv or one of its more modern equivalents.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions