In XView and Motif, events (such as resizing, painting, mouse clicks, button presses) are handled by a rather arbitrary collection of optional XView and Xlib callbacks. In MS Windows, events are messages which are handled by a window procedure, or ignored.
In wxWindows, an application's GUI objects mostly receive events by wxWindows calling user-overridable handlers, such as OnEvent, OnChar and OnSize. Frames can receive OnClose events from the window manager (X) or system control menu (MS Windows). These events are handled by the application by deriving new frame classes and overriding the event-handling member functions.
Panel item notification has to be handled rather differently. In MS Windows, all panel item events (such as a button press) are sent to the parent window (requiring large case statements to differentiate the events), and all window events are sent to the relevant window. In XView and Motif, different types of callback function have to be defined, depending on the event.
In wxWindows, panel items have optional callback functions, but there is only one callback type: the function takes the object and a command event structure. The class derivation approach cannot be extended to panel items since it does not make sense to derive a new class for every individual panel item created.
From wxWindows 1.61, panel items that do not have callbacks defined for them use their parent panel (or dialog box) to notify events, via the OnCommand virtual member function. This is essential when loading dialogs and panels from resources, since callback functions cannot be specified in a resource file. So in such cases, the programmer must derive a new panel or dialog class in order to override this member function and intercept events. The panel item calling the function can be identified by giving each panel item a unique name, and using wxWindow::GetName inside the OnCommand function.
From wxWindows 1.62, all window classes derive from wxEvtHandler, and a window's event handler, which defaults to point to itself, can be changed without the need for deriving a new class. This decoupling of event handling code from the window object itself makes it possible to override behaviour, perhaps temporarily; example applications might be dialog editors and on-line tutorial systems that need to intercept user input. It also gives another method of handling panel item input, by setting an event handler object for the panel item or panel item's parent.
From Version 1.5, wxWindows has its own event system. Event classes are derived from the abstract base class wxEvent (which used to serve as a holder for canvas and panel item events). An event class encapsulates a range of similar event types. For example, the instances of the wxMouseEvent class may be generated for a number of event types such as wxEVENT_TYPE_LEFT_DOWN.
There are several motivations for having an explicit representation for events.
Firstly, encapsulating events in structures makes sense compared with passing an event handler a large number of arguments.
Secondly, user input events may be simulated by sending events; this can be used for automating GUI testing, and events could (in theory) be stored for later playback.
Thirdly, event handlers can be installed by programs or 'meta-programs' which want to override or examine program behaviour. For example, special-needs access code could be written to enable GUI events to be expressed to the user in a non-graphical form. Or, a meta-program could examine the dialog structure of a running application and output a skeleton help file corresponding to the application's hierarchy of menus and dialogs, taking some of the donkey work out of preparing on-line help.
The event system is meant to be user-extensible so that any GUI-related or application-specific events may be defined and used in a consistent way. However, it is not yet completed and documented, and it is expected to evolve over the next few releases. The eventual aim is an event system which is comprehensive enough to enable wxWindows programs to be tested automatically using scripts (possibly using NASA's CLIPS as the scripting language -- see CLIPS).