Event binders consist of instances of the class wx.PyEventBinder. A predefined instance of wx.PyEventBinder is provided for all of the event types supported, and you can create your own event binders for your custom event types when needed. There is one event binder instance for each event type, which means that multiple binders may correspond to any one wx.Event subclass. This is because event types are more detailed than wx.Event subclasses. For example, the wx.Mouse-Event class has fourteen separate event types, each of which uses the same basic information about the state of the mouse when the event is triggered by a user action (i.e., left click, right click, double click).
In wxPython, names of the event binder instances are global. In order to clearly associate event types with handlers, these names start with wx.EVT_ and correspond to the names of the macros used in the C + + wxWidgets code. When discussing wxPython code, the tendency is to use the wx.EVT_ binder name as a stand-in for the actual event type. As a result, it's worth highlighting that the value of the wx.EVT binder name is not the actual integer code used for event typing that you'd receive by calling the GetEventType() method of a wx.Event instance. Event-type integer codes have an entirely different set of global names, and are not often used in practice.
As an example of the wx.EVT names, let's look at the event types of wx.Mouse-Event. As we just mentioned, there are fourteen of them, nine of which cover mouse down, mouse up, or double click events based on the button clicked. Those nine event types use the following names:
Additionally, the type wx.evt_motion is caused by the user moving the mouse. The types wx.enter_window and wx.leave_window are caused when the mouse enters or leaves any widget. The wx.evt_mousewheel type is bound to the movement of a mouse scroll wheel. Finally, you can bind all mouse events to a single function at one time using the wx.EVT_MOUSE_EVENTS type.
Similarly, the wx.CommandEvent class has 28 different event types associated with it; although several are only for older Windows operating systems. Most of these are specific to a single widget, such as wx.evt_button for a button click, and wx.evt_menu for a menu item selection. Command events for specific widgets are described with that widget when it is discussed in part 2.
The advantage of this binding mechanism is that it allows wxPython to dispatch events on a very granular basis, while still allowing similar events to be instances of the same class, and to share data and functionality. This makes writing event handlers much cleaner in wxPython than in other interface toolkits.
Event binders are used to connect a wxPython widget with an event object and a handler function. This connection allows the wxPython system to respond to an event on that widget by executing the code in the handler function. In wxPython, any object which can respond to an event is a subclass of wx.EvtHandler. All window objects are a subclass of wx.EvtHandler, so every widget in a wxPython application can respond to events. The wx.EvtHandler class can also be used by non-widget objects, such as wx.App, so event handling functionality is not limited to display-able widgets. To clarify the terminology, saying that a widget can respond to events means that the widget can create event bindings which wxPython recognizes during dispatch. The actual code called by a binder in the event handler function is not necessarily located in a wx.EvtHandler class.
Was this article helpful?