// key code is within legal range. we call event.Skip() so the
// event can be processed either in the base wxWindows class
// or the native control.
-
- event.Skip();
+
+ event.Skip();
}
else
{
// illegal key hit. we don't call event.Skip() so the
// event is not processed anywhere else.
-
+
wxBell();
}
}
\item Finally, {\bf ProcessEvent} is called on the wxApp object.
\end{enumerate}
+{\bf Pay close attention to Step 5.} People often overlook or get
+confused by this powerful feature of the wxWindows event processing
+system. To put it a different way, events derived either directly or
+indirectly from wxCommandEvent will travel up the containment
+heirarchy from child to parent until an event handler is found that
+doesn't call event.Skip(). Events not derived from wxCommandEvent are
+sent only to the window they occurred in and then stop.
+
+Typically events that deal with a window as a window (size, motion,
+paint, mouse, keyboard, etc.) are sent only to the window. Events
+that have a higher level of meaning and/or are generated by the window
+itself, (button click, menu select, tree expand, etc.) are command
+events and are sent up to the parent to see if it is interested in the
+event.
+
Note that your application may wish to override ProcessEvent to redirect processing of
events. This is done in the document/view framework, for example, to allow event handlers
to be defined in the document or view. To test for command events (which will probably
\twocolitem{\helpref{wxPaintEvent}{wxpaintevent}}{A paint event}
\twocolitem{\helpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent}}{Used to query layout information}
\twocolitem{\helpref{wxSizeEvent}{wxsizeevent}}{A size event}
+\twocolitem{\helpref{wxScrollWinEvent}{wxscrollwinevent}}{A scroll event sent by a scrolled window (not a scroll bar)}
\twocolitem{\helpref{wxSysColourChangedEvent}{wxsyscolourchangedevent}}{A system colour change event}
\twocolitem{\helpref{wxUpdateUIEvent}{wxupdateuievent}}{A user interface update event}
\end{twocollist}
\twocolitem{\helpref{wxMouseEvent}{wxmouseevent}}{Mouse event macros can handle either individual
mouse events or all mouse events.}
\twocolitem{\helpref{wxMoveEvent}{wxmoveevent}}{The EVT\_MOVE macro is used to handle a window move.}
-\twocolitem{\helpref{wxUpdateUIEvent}{wxupdateuievent}}{The EVT\_UPDATE\_UI macro is used to handle user interface
-update pseudo-events, which are generated to give the application the chance to update the visual state of menus,
-toolbars and controls.}
\twocolitem{\helpref{wxPaintEvent}{wxpaintevent}}{The EVT\_PAINT macro is used to handle window paint requests.}
\twocolitem{\helpref{wxScrollEvent}{wxscrollevent}}{These macros are used to handle scroll events from
-windows, \helpref{wxScrollBar}{wxscrollbar}, and \helpref{wxSpinButton}{wxspinbutton}.}
+\helpref{wxScrollBar}{wxscrollbar}, \helpref{wxSlider}{wxslider},and \helpref{wxSpinButton}{wxspinbutton}.}
\twocolitem{\helpref{wxSizeEvent}{wxsizeevent}}{The EVT\_SIZE macro is used to handle a window resize.}
+\twocolitem{\helpref{wxSplitterEvent}{wxsplitterevent}}{The EVT\_SPLITTER\_SASH\_POS\_CHANGED, EVT\_SPLITTER\_UNSPLIT
+and EVT\_SPLITTER\_DOUBLECLICKED macros are used to handle the various splitter window events.}
\twocolitem{\helpref{wxSysColourChangedEvent}{wxsyscolourchangedevent}}{The EVT\_SYS\_COLOUR\_CHANGED macro is used to handle
events informing the application that the user has changed the system colours (Windows only).}
\twocolitem{\helpref{wxTreeEvent}{wxtreeevent}}{These macros handle \helpref{wxTreeCtrl}{wxtreectrl} events.}
+\twocolitem{\helpref{wxUpdateUIEvent}{wxupdateuievent}}{The EVT\_UPDATE\_UI macro is used to handle user interface
+update pseudo-events, which are generated to give the application the chance to update the visual state of menus,
+toolbars and controls.}
\end{twocollist}