documented that wxHSCROLL disables wrapping; added comment to the source

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

diff --git a/docs/latex/wx/tevent.tex b/docs/latex/wx/tevent.tex
index b3cf6814fdc3d3b02633c11605cbb584c4776681..7d746e98de00c7f84053109efd7f7062e5a55ad2 100644 (file)
--- a/docs/latex/wx/tevent.tex
+++ b/docs/latex/wx/tevent.tex
@@ -142,18 +142,20 @@ class table is tried, and so on until no more tables exist or an appropriate fun
 in which case the function exits.
 \item The search is applied down the entire chain of event handlers (usually the chain has a length
 of one). If this succeeds, the function exits.
-\item If the object is a wxWindow and the event is a wxCommandEvent, {\bf ProcessEvent} is
-recursively applied to the parent window's event handler. If this returns true, the function exits.
+\item If the object is a wxWindow and the event is set to set to propagate (in the library only
+wxCommandEvent based events are set to propagate), {\bf ProcessEvent} is recursively applied
+to the parent window's event handler. If this returns true, the function exits.
 \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
-hierarchy 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.
+system.  To put it a different way, events set to propagate 
+(\helpref{See: wxEvent::ShouldPropagate}{wxeventshouldpropagate})
+(most likely derived either directly or indirectly from wxCommandEvent)
+will travel up the containment hierarchy from child to parent until the 
+maximal propagation level is reached or an event handler is found that
+doesn't call \helpref{event.Skip()}{wxeventskip}.
 
 Finally, there is another additional complication (which, in fact, simplifies
 life of wxWindows programmers significantly): when propagating the command
@@ -182,12 +184,13 @@ 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
-be the only events you wish to redirect), you may use wxEvent::IsCommandEvent for
-efficiency, instead of using the slower run-time type system.
+be the only events you wish to redirect), you may use 
+\helpref{wxEvent::IsCommandEvent}{wxeventiscommandevent} for efficiency, 
+instead of using the slower run-time type system.
 
 As mentioned above, only command events are recursively applied to the parents event
-handler. As this quite often causes confusion for users, here is a list of system
-events which will NOT get sent to the parent's event handler:
+handler in the libary itself. As this quite often causes confusion for users,
+here is a list of system events which will NOT get sent to the parent's event handler:
 
 \begin{twocollist}\itemsep=0pt
 \twocolitem{\helpref{wxEvent}{wxevent}}{The event base class}
@@ -316,6 +319,19 @@ you can use identifiers below wxID\_LOWEST.
 #define wxID_FIND               5034
 #define wxID_DUPLICATE          5035
 #define wxID_SELECTALL          5036
+#define wxID_DELETE             5037
+#define wxID_REPLACE            5038
+#define wxID_REPLACE_ALL        5039
+#define wxID_PROPERTIES         5040
+
+#define wxID_VIEW_DETAILS       5041
+#define wxID_VIEW_LARGEICONS    5042
+#define wxID_VIEW_SMALLICONS    5043
+#define wxID_VIEW_LIST          5044
+#define wxID_VIEW_SORTDATE      5045
+#define wxID_VIEW_SORTNAME      5046
+#define wxID_VIEW_SORTSIZE      5047
+#define wxID_VIEW_SORTTYPE      5048
 
 #define wxID_FILE1              5050
 #define wxID_FILE2              5051