Menu/toolbar event handling now tries the window with the focus first.

wxTextCtrl processes cut, copy, paste, undo, redo commands and UI updates
automatically.


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

docs/latex/wx/menu.tex

@@ -383,7 +383,15 @@ A menu bar is a series of menus accessible from the top of a frame.
 \wxheading{Event handling}
 
 To respond to a menu selection, provide a handler for EVT\_MENU, in the frame
-that contains the menu bar.
+that contains the menu bar. If you have a toolbar which uses the same identifiers
+as your EVT\_MENU entries, events from the toolbar will also be processed by your
+EVT\_MENU event handlers.
+
+Note that menu commands (and UI update events for menus) are first sent to
+the focus window within the frame. If no window within the frame has the focus,
+then the events are sent directly to the frame. This allows command and UI update
+handling to be processed by specific windows and controls, and not necessarily
+by the application frame.
 
 \wxheading{See also}
 

docs/latex/wx/tevent.tex

@@ -134,7 +134,9 @@ recursively applied to the parent window's event handler. If this returns TRUE,
 
 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 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.
 
 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
@@ -164,7 +166,21 @@ In some cases, it might be desired by the programmer to get a certain number
 of system events in a parent window, for example all key events sent to, but not
 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. See next section.
+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.
 
 \subsection{Pluggable event handlers}
 

docs/latex/wx/text.tex

@@ -52,6 +52,10 @@ wxTextCtrl header file.
 
 \wxheading{Event handling}
 
+The following commands are processed by default event handlers in wxTextCtrl: wxID\_CUT, wxID\_COPY,
+wxID\_PASTE, wxID\_UNDO, wxID\_REDO. The associated UI update events are also processed
+automatically, when the control has the focus.
+
 To process input from a text control, use these event handler macros to direct input to member
 functions that take a \helpref{wxCommandEvent}{wxcommandevent} argument.
 

docs/latex/wx/toolbar.tex

@@ -62,6 +62,13 @@ window is passed and the tool id is retrieved from the wxCommandEvent.
 This is because the id may be -1 when the mouse moves off a tool, and -1 is not
 allowed as an identifier in the event system.
 
+Note that tool commands (and UI update events for tools) are first sent to
+the focus window within the frame that contains the toolbar. If no window within the frame has the focus,
+then the events are sent directly to the toolbar (and up the hierarchy to the
+frame, depending on where the application has put its event handlers). This allows command and UI update
+handling to be processed by specific windows and controls, and not necessarily
+by the application frame.
+
 \twocolwidtha{7cm}
 \begin{twocollist}\itemsep=0pt
 \twocolitem{{\bf EVT\_TOOL(id, func)}}{Process a wxEVT\_COMMAND\_TOOL\_CLICKED event

docs/latex/wx/ttoolbar.tex

@@ -13,8 +13,7 @@ Instead of supplying one toolbar class with a number
 of different implementations depending on platform, wxWindows separates
 out the classes. This is because there are a number of different toolbar
 styles that you may wish to use simultaneously, and also, future
-toolbar implementations will emerge (for example, using the
-new-style Windows `coolbar' as seen in Microsoft applications) which
+toolbar implementations will emerge which
 cannot all be shoe-horned into the one class.
 
 For each platform, the symbol {\bf wxToolBar} is defined to be one of the
@@ -26,7 +25,7 @@ The following is a summary of the toolbar classes and their differences.
 \item {\bf wxToolBarBase.} This is a base class with pure virtual functions,
 and should not be used directly.
 \item {\bf wxToolBarSimple.} A simple toolbar class written entirely with generic wxWindows
-functionality. A simply 3D effect for buttons is possible, but it is not consistent
+functionality. A simple 3D effect for buttons is possible, but it is not consistent
 with the Windows look and feel. This toolbar can scroll, and you can have arbitrary
 numbers of rows and columns.
 \item {\bf wxToolBarMSW.} This class implements an old-style Windows toolbar, only on
@@ -39,7 +38,8 @@ CreateTools must be called after the tools have been added.
 No absolute positioning is supported but you can specify the number
 of rows, and add tool separators with {\bf AddSeparator}.
 Tooltips are supported. {\bf OnRightClick} is not supported. This is the default wxToolBar
-on Windows 95, Windows NT 4 and above.
+on Windows 95, Windows NT 4 and above. With the style wxTB\_FLAT, the flat toolbar
+look is used, with a border that is highlit when the cursor moves over the buttons.
 \end{itemize}
 
 A toolbar might appear as a single row of images under
@@ -61,8 +61,6 @@ as the demo shows, before adding tools to the button bar. Don't supply more than
 one bitmap for each tool, because the toolbar generates all three images (normal,
 depressed and checked) from the single bitmap you give it.
 
-To intercept
-
 \subsection{Using the toolbar library}
 
 Include {\tt "wx/toolbar.h"}, or if using a class directly, one of:
@@ -74,7 +72,9 @@ Include {\tt "wx/toolbar.h"}, or if using a class directly, one of:
 \end{itemize}
 
 Example of toolbar use are given in the sample program ``toolbar''. The
-source is given below.
+source is given below. In fact it's out of date because recommended
+practise is to use event handlers (using EVT\_MENU or EVT\_TOOL) instead of
+overriding OnLeftClick.
 
 {\small
 \begin{verbatim}