]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/latex/wx/tevent.tex
clarified global and local config files behavior
[wxWidgets.git] / docs / latex / wx / tevent.tex
index 8d9c75632c489d6bed526d25950bfa4ba5be41b8..e747b0671440123ad5759075b7c1427de0dbca17 100644 (file)
@@ -236,8 +236,7 @@ the user-generated events. The only {\bf exceptions} to this rule are:
 \twocolitem{\helpref{wxTreeCtrl::Delete}{wxtreectrldelete}}{No event-free alternatives}
 \twocolitem{\helpref{wxTreeCtrl::DeleteAllItems}{wxtreectrldeleteallitems}}{No event-free alternatives}
 \twocolitem{\helpref{wxTreeCtrl::EditLabel}{wxtreectrleditlabel}}{No event-free alternatives}
-\twocolitem{All \helpref{wxTextCtrl}{wxtextctrl} methods}\
-{\helpref{wxTextCtrl::ChangeValue}{wxtextctrlchangevalue} can be used instead
+\twocolitem{All \helpref{wxTextCtrl}{wxtextctrl} methods}{\helpref{wxTextCtrl::ChangeValue}{wxtextctrlchangevalue} can be used instead
 of \helpref{wxTextCtrl::SetValue}{wxtextctrlsetvalue} but the other functions,
 such as \helpref{Replace}{wxtextctrlreplace} or \helpref{WriteText}{wxtextctrlwritetext} 
 don't have event-free equivalents}
@@ -269,7 +268,8 @@ defining the appropriate event table, and then call
 \rtfsp\helpref{wxWindow::SetEventHandler}{wxwindowseteventhandler} (or, preferably,
 \rtfsp\helpref{wxWindow::PushEventHandler}{wxwindowpusheventhandler}) to make this
 event handler the object that responds to events. This way, you can avoid
-a lot of class derivation, and use the same event handler object to
+a lot of class derivation, and use the same event handler class (but different
+objects as the same event handler object shouldn't be used more than once) to
 handle events from instances of different classes. If you ever have to call a window's event handler
 manually, use the GetEventHandler function to retrieve the window's event handler and use that
 to call the member function. By default, GetEventHandler returns a pointer to the window itself
@@ -441,16 +441,21 @@ and this is done using the following macros:
 
 \begin{verbatim}
 // in the header of the source file
+BEGIN_DECLARE_EVENT_TYPES()
 DECLARE_EVENT_TYPE(name, value)
+END_DECLARE_EVENT_TYPES()
 
 // in the implementation
 DEFINE_EVENT_TYPE(name)
 \end{verbatim}
 
 You can ignore the {\it value} parameter of the DECLARE\_EVENT\_TYPE macro
-since it used only for backwards compatibility with wxWidgets 2.0.x based
+since it is used only for backwards compatibility with wxWidgets 2.0.x based
 applications where you have to give the event type ID an explicit value.
 
+See also the \helpref{event sample}{sampleevent} for an example of code
+defining and working with the custom event types.
+
 \wxheading{Using existing event classes}
 
 If you just want to use a \helpref{wxCommandEvent}{wxcommandevent} with
@@ -509,9 +514,9 @@ but responds to a range of window identifiers.}
 expects a member function with a wxCommandEvent argument.}
 \twocolitem{\windowstyle{EVT\_COMMAND\_RANGE(id1, id2, event, func)}}{The same as EVT\_CUSTOM\_RANGE, but
 expects a member function with a wxCommandEvent argument.}
-\twocolitem{\windowstyle{EVT\_NOTIFY(id, event, func)}}{The same as EVT\_CUSTOM, but
+\twocolitem{\windowstyle{EVT\_NOTIFY(event, id, func)}}{The same as EVT\_CUSTOM, but
 expects a member function with a wxNotifyEvent argument.}
-\twocolitem{\windowstyle{EVT\_NOTIFY\_RANGE(id1, id2, event, func)}}{The same as EVT\_CUSTOM\_RANGE, but
+\twocolitem{\windowstyle{EVT\_NOTIFY\_RANGE(event, id1, id2, func)}}{The same as EVT\_CUSTOM\_RANGE, but
 expects a member function with a wxNotifyEvent argument.}
 \end{twocollist}