An event-driven program is mainly a control structure that receives events and responds to them. The structure of a wxPython program (or of any event-driven program) is fundamentally different from that of an ordinary Python script. A typical Python script has a specific starting point and a specific ending point, and the programmer controls the order of execution using conditionals, loops, and functions. The program is not linear, but its order is often independent of user action.
From the users perspective, a wxPython program spends much of its time doing nothing. Typically, it is idle until the user or the system does something to
trigger the wxPython program into action. The wxPython program structure is an example of an event-driven program architecture. Figure 3.1 shows a simple diagram outlining the major parts of an event-driven program.
Think of the main loop of an event-driven system as analogous to an operator at a customer service call center. When no calls are coming in, the operator is, as they say, standing by. Eventually, an event occurs, such as the phone ringing. The operator initiates a response process, which involves talking to the customer until the operator has enough information to dispatch the customer to the proper respondent for her call. The operator then waits for the next event.
Although each event-driven system is somewhat different, there are many similarities between them. The primary characteristics of an event-driven program structure are as follows:
■ After the initial setup, the program spends most of its time in an idle loop, where it does little or no information processing. Entering into this loop signifies the beginning of the user-interactive part of the program, and exiting the loop signifies its end. In wxPython, this loop is the method wx.App.MainLoop(), and is explicitly invoked in your script. The main loop is automatically exited when all top-level windows are closed.
■ The program contains events that correspond to things that happen in the program environment. Events are typically triggered by user activity, but can also be the result of system activity, or arbitrary code elsewhere in the program. In wxPython, all events are instances of the class wx.Event or one of its subclasses. Each event has an event type attribute (see table 3.1) that allows different kinds of events to be distinguished. For example, a mouse up and mouse down event are both delivered as instances of the same class, but have a different event type.
■ As part of the idle loop, the program periodically checks to see whether anything requiring a response has happened. There are two mechanisms by which an event-driven system may be notified about events. The more popular method, used by wxPython, posts the events to a central queue, which triggers processing of that event. Other event-driven systems use a polling method, where possible raisers of events are periodically queried by the central process and asked if they have any events pending.
■ When an event takes place, the event-based system processes the event in an attempt to determine what code, if any, should be executed. In wxPython, native system events are translated to wx.Event instances and then given to the method wx.EvtHandler.ProcessEvent() for dispatching out to the proper handler code. Figure 3.3 presents a basic overview of the process. The component parts of the event mechanism are event binder objects and event handlers, both defined in table 3.1. An event binder is a predefined wxPython object. There is a separate event binder for each event type. An event handler is a function or method that takes a wxPython event instance as an argument. An event handler is invoked when the user triggers the appropriate event.
Next, we'll discuss more details about wxPython, beginning with the basic unit of event response, the event handler.
Was this article helpful?