Small fixes for Tex2RTF but alas, we still get memory problems.

[wxWidgets.git] / docs / latex / wx / tevent.tex

diff --git a/docs/latex/wx/tevent.tex b/docs/latex/wx/tevent.tex
index 6f27ee8060a13f5db63c822a1dbed7a164c5c87e..e6b7cb9382bf1c76d1b77cabdc2b3496e2b6e5b7 100644 (file)
--- a/docs/latex/wx/tevent.tex
+++ b/docs/latex/wx/tevent.tex
@@ -100,14 +100,14 @@ void MyTextCtrl::OnChar(wxKeyEvent& event)
        // 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();
     }
 }
@@ -132,6 +132,21 @@ recursively applied to the parent window's event handler. If this returns TRUE,
 \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
@@ -158,6 +173,7 @@ events which will NOT get sent to the parent's event handler:
 \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}
@@ -168,19 +184,22 @@ used by, the native controls in a dialog. In this case, a special event handler
 will have to be written that will override ProcessEvent() in order to pass
 all events (or any selection of them) to the parent window.
 
-\subsection{Redirection of command events to the window with the focus}
-
-The usual upward search through the window hierarchy for command event
-handlers does not always meet an application's requirements. Say you have two
-wxTextCtrl windows in a frame, plus a toolbar with Cut, Copy and Paste
-buttons. To avoid the need to define event handlers in the frame
-and redirect them explicitly to the window with the focus, command events
-are sent to the window with the focus first, for
-menu and toolbar command and UI update events only. This means that
-each window can handle its own commands and UI updates independently. In
-fact wxTextCtrl can handle Cut, Copy, Paste, Undo and Redo commands and UI update
-requests, so no extra coding is required to support them in your menus and
-toolbars.
+% VZ: it doesn't work like this, but just in case we ever reenable this
+%     behaviour, I leave it here
+%
+% \subsection{Redirection of command events to the window with the focus}
+% 
+% The usual upward search through the window hierarchy for command event
+% handlers does not always meet an application's requirements. Say you have two
+% wxTextCtrl windows in a frame, plus a toolbar with Cut, Copy and Paste
+% buttons. To avoid the need to define event handlers in the frame
+% and redirect them explicitly to the window with the focus, command events
+% are sent to the window with the focus first, for
+% menu and toolbar command and UI update events only. This means that
+% each window can handle its own commands and UI updates independently. In
+% fact wxTextCtrl can handle Cut, Copy, Paste, Undo and Redo commands and UI update
+% requests, so no extra coding is required to support them in your menus and
+% toolbars.
 
 \subsection{Pluggable event handlers}
 
@@ -323,7 +342,7 @@ mouse events or all mouse events.}
 \twocolitem{\helpref{wxMoveEvent}{wxmoveevent}}{The EVT\_MOVE macro is used to handle a window move.}
 \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.}