Event programming and why it is relevant to Tcl/Tk programming

Event-driven programming is the style used when writing graphical user interfaces in Tk.

See Also

BLT's bgexec

An even easier realization of asynchronous processing.

Tcllib's uevent

A general system for Tcl similar to the Tk event command.

Examples

Countdown program

A simple example of converting a loop-based program to an event-driven one.

Description

In a graphical user interface things happen at unpredictable times. A user might for example select a row in a table while the program is communicating with a remote server. These two events may be unrelated, and the order in which they occur might not have particular meaning for the program. Moreover, an interface typically should remain responsive even when the program is waiting for data on some channel. In event-driven programming the program maintains a queue of events that have occurred and responds to those events as it can. Tcl provides an event loop which starts when one calls vwait. Tk itself calls vwait on startup, making it unnecessary for the main script to do it.

Major classes of events in Tcl/Tk

• GUI events - Tk's raison d'etre. Note that this includes send and various wm subcommands as well as bind and the -command options to various widgets...
• File events - These occur when it becomes possible to either read from or write to a channel (especially to a pipe, socket or serial port.)
• Timer events - Great for scheduling things for happening later, and brilliant for use with periodic activity.
• Idle events - Useful for when you wish to put something off until there is nothing to do except wait for events (mainly used in the management of display updates...)
• Virtual events - Comes in handy when a certain program state which is reached should call a proc at a higher abstraction level of the application program. It is not good practice to call a high level proc from a lower level. event generate is helpful because (a) the programmer specifies a name for the virtual event (hence a low level software module is consistent in having defined names for ALL internal resources which can be used by apps) and (b) the event can simply be ignored when not needed.

There are also conditions that are internal to a program that can be best thought of as being events:

• Variable accesses — see Traces
• Background error handling (Lars H, 2008-09-15: AFAICT this really goes through the event loop nowadays.) — see bgerror and interp bgerror.
• Unrecognized command handling — see unknown and namespace unknown.

Caveat: there is a difference between these actions, and the 'real' events listed above. Those events happen when the event loop is entered, but the ones listed here happen directly in the processing of the current code. To see what I mean compare when traces on variable writes occur vs. a section of code doing a vwait on the same variable.

User-defined Events

What would it take for Tcl's event handling to support user defined events? Perhaps I want to generate events based on encounters of particular tokens during input file parsing, etc. Does this kind of thing currently event? Can one bind to these events so that code gets called automatically upon the raising of a user event?

KBK 2001-08-09: User defined events exist in Tk, but they're limited to UI components. See event with particular attention to event generate. It would be nice to have event bindings on other sorts of things. Michael McLennan's keynote speech at the 2001 Tcl conference put forward a proposal for non-GUI event definitions. Is that on the Web anywhere?

Yes. http://conferences.oreillynet.com/pub/w/10/tcl_presentations.html (That appears to have his paper - but not any of the material from his keynote speech, Dealing with my Tcl addiction, which is where he brought up the notification system with which he and George Howlett had been experimenting.)

trigger is mentioned in one paper - see that page for the PDF of the paper. However, I've not seen where the code itself is available.

2010-12-14 A TIP to address this issue is under discussion: TIP #379