wxPython doc updates

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@4262 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

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