Event Driven Programming

So far we have been looking at batch oriented programs. Recall that programs can be batch oriented, whereby they start, do something then stop, or event driven where they start, wait for events and only stop when told to do so - by an event. How do we create an event driven program? We'll look at this in two ways - first we will simulate an event environment then we'll create a very simple GUI program that uses the operating system and environment to generate events.

Simulating an Event Loop

Every event driven program has a loop somewhere that catches received events and processes them. The events may be generated by the operating system, as happens with virtually all GUI programs or the program itself may go looking for events as is often the case in embedded control systems such as used in cameras etc.

We will create a program that looks for precisely one type of event - keyboard input - and processes the results until some quit event is received. In our case the quit event will be the space key. We will process the incoming events in a very simple manner - we will simply print the ASCII code for that key. We'll use BASIC for this because it has a nice,. easy to use function for reading keys one at a time - INKEY$.

First we implement the main program body which simply starts up the event gathering loop and calls the event handling subroutines when a valid event is detected.

' Declare the subroutines that will handle the events
DECLARE SUB dokeyevent (keypress AS STRING)
DECLARE SUB doquitevent (keypress AS STRING)

' First, clear the screen of clutter then warn the user 
' of what to do to quit
CLS
PRINT "Hit space to end..."
PRINT

' Now loop forever
WHILE 1
        ky$ = INKEY$
        length = LEN(ky$)
        IF length <> 0 THEN
        ' send events to event handling functions
            IF ky$ <> " " THEN
                CALL doKeyEvent(ky$)
            ELSE 
                CALL doQuitEvent(ky$)
            END IF
        END IF
WEND

Notice that what we do with the events is of no interest to the main body, it simply collects the events and passes them to the event handlers. This independance of event capture and processing is a key feature of event driven programming.

Now we can implement the 2 event handlers. The first, doKeyEvent simply prints out the ASCII value of the key pressed:

SUB doKeyEvent (keypress AS STRING)
    ' print valid keystrokes
    length = LEN(keypress)
    IF length = 1 THEN 'its simple ASCII
       PRINT ASC(keypress)
    ELSE
       IF length = 2 THEN 
          'its non alphanumeric so use the 2nd char 
          PRINT ASC(MID$(keypress, 2, 1))
       END IF
    END IF
END SUB

The doQuitEvent is trivial - it justs STOPs the program!

SUB doQuitEvent (keypress AS STRING)
    STOP
END SUB

If we were creating this as a framework for use in lots of projects we would probably include a call to an initialisation function at the start and a cleanup function at the end. The programmer could then use the loop part and provide his own initialisation, processing and cleanup functions.

That's exactly what most GUI type environments do, in that the loop part is embedded in the operating environment or framework and applications are contractually required to provide the event handling functions and hook these into the event loop in some way.

Let's see that in action as we explore Python's Tkinter GUI library.

A GUI program

For this exercise we'll use the Python Tkinter toolkit. This is a Python wrapper around the Tk toolkit originally written as an extension to Tcl and also available for Perl. The Python version is an object oriented framework which is, in my opinion, considerably easier to work with than the original procedural Tk version. I am not going to dwell much on the GUI aspects of this, rather I want to focus on the style of programming - using Tkinter to handle the event loop and leaving the programmer to create the initial GUI and then process the events as they arrive.

In the example we create an application class KeysApp which creates the GUI in the __init__ method and binds the space key to the doQuitEvent method. The class also defines the required doQuitEvent method.

The GUI itself simply consists of a text entry widget whose default behaviour is to echo characters typed onto the display.

Creating an application class is quite common in OO event driven environments because there is a lot of synergy between the concepts of events being sent to a program and messages being sent to an object. The two concepts map on to each other very easily. An event handling function thus becomes a method of the application class.

Having defined the class we simply create an instance of it and then send it the mainloop message.

The code looks like this:

# Use from X import * to save having to preface everything 
# as tkinter.xxx
from Tkinter import *

# Create the application class which defines the GUI 
# and the event handling methods
class KeysApp(Frame):
    def __init__(self):
        Frame.__init__(self)
        self.txtBox = Text(self)
        self.txtBox.bind("<space>", self.doQuitEvent)
        self.txtBox.pack()
        self.pack()

    def doQuitEvent(self,event):
        import sys
        sys.exit()
        

# Now create an instance and start the event loop running
myApp = KeysApp()
myApp.mainloop()

Of course in the BASIC version we printed the ASCII codes of all keys rather than only printing the alphanumeric versions of printable keys as we do here. There's nothing to prevent us capturing all of the keypresses and doing the same thing. To do so we would add the following line to the __init__ method:

self.txtBox.bind("<Key>", self.doKeyEvent)

And the following method to process the event:

def doKeyEvent(self,event):
    str = "%d\n" % event.keycode
    self.txtBox.insert(END, str)
    return "break"

Note 1: the key value is stored in the keycode field of the event. I had to look at the source code of Tkinter.py to find that out... Recall that curiosity is a key attribute of a programmer?

Note 2: return "break" is a magic signal to tell Tkinter not to invoke the default event processing for that widget. Without that line, the text box displays the ASCII code followed by the actual character typed, which is not what we want here.

That's enough for now. This isn't meant to be a tutorial on Tkinter, thats the subject of the next topic. There are also several books on using TK and Tkinter.