Summary

■ A wxPython application uses an event-based flow of control. Most of the application's time is spent in a main loop, waiting for events and dispatching them to the appropriate handler function.

■ All wxPython events are subclasses of the class wx.Event. Lower level events, such as mouse clicks, are used to build up higher order events, such as button clicks or menu item selections. These higher order events that result from wxPython widgets are subclasses of the class wx.CommandEvent. Most event classes are further classified by an event type field which differentiates between events that may all use the same data set.

■ To capture the relationship between events and functions, wxPython uses instances of the class wx.PyEventBinder. There are many predefined instances of this class, each corresponding to a specific event type. Every wxPython widget is a subclass of wx.EvtHandler. The wx.EvtHandler class has a method Bind(), which is usually called at initialization with an event binder instance and a handler function as arguments. Depending on the type of event, other wxPython object IDs may also need to be passed to the Bind() call.

■ Events are generally sent to the object that generated them to search for a binding object which binds it to a handler. If the event is a command event, the event propagates upward through the container hierarchy until a widget is found that has a handler for the event type. Once an event handler is found, processing on that event stops, unless the handler calls the Skip() method of the event. You can use the Skip() method to allow multiple handlers to respond to a single event, or to verify that all the default behavior for the event occurs. Certain aspects of the main loop can be controlled using methods of wx.App.

■ Custom events can be created in wxPython, and emitted as part of the behavior of a custom widget. Custom events are subclasses of wx.PyEvent, custom command events are subclasses of wx.PyCommandEvent. To create a custom event, the new class must be defined, and a binder object must be created for each event type managed by the new class. Finally, the event must be generated somewhere in the system by passing a new instance to the event handler system via the ProcessEvent() method.

In this chapter, we've covered the application objects that are most important to your wxPython application. In the next chapter, we'll show you a useful tool, written using wxPython, that will also assist you with wxPython development work.

Was this article helpful?

0 0

Post a comment