The wxPython event handling procedure was designed to make it simple for the programmer to create event bindings in what are generally the most obvious places, while ignoring unimportant events. As is often the case in simple design, the underlying mechanism is actually a bit complex. Next, we'll trace the procedure for a button click event and a mouse entering event.
Figure 3.3 displays a basic flow chart of event handling process. Rectangles indicate the start and end of the process, circles indicate various wxPython objects that are part of the process, diamonds indicate decision points, and rectangles with bars indicate actual event handler methods.
The event process begins with the object that triggered the event. Typically, wxPython looks first at the triggering object for a bound handler function matching the event type. If one is found, the method is executed. If not, wxPython checks to see if the event propagates up the container hierarchy. If so, the parent widget is checked, up the hirerarchy, until wxPython either finds a handler function or hits a top-level object. If the event doesn't propagate, wxPython still checks the application object for a handler method before finishing. When an event handler is run, the process typically ends. However, the function can tell wxPython to continue searching for handlers.
Let's take a closer look at each step of the process. Before discussing each step, we'll display a thumbnail for each relevant part of Figure 3.3.
Was this article helpful?