Added event table macros to wxGrid that take window identifiers

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

diff --git a/docs/latex/wx/evthand.tex b/docs/latex/wx/evthand.tex
index ab602afed66e9ead8a427673f5f3cbb2cf53774c..60d9ee90e301f93920c705d7e3027f8866117edf 100644 (file)
--- a/docs/latex/wx/evthand.tex
+++ b/docs/latex/wx/evthand.tex
@@ -4,6 +4,12 @@ A class that can handle events from the windowing system.
 wxWindow (and therefore all window classes) are derived from
 this class.
 
 wxWindow (and therefore all window classes) are derived from
 this class.
 

+When events are received, wxEvtHandler invokes the method listed in the
+event table using itself as the object.  When using multiple inheritance
+it is imperative that the wxEvtHandler(-derived) class be the first
+class inherited such that the "this" pointer for the overall object
+will be identical to the "this" pointer for the wxEvtHandler portion.
+

 \wxheading{Derived from}
 
 \helpref{wxObject}{wxobject}
 \wxheading{Derived from}
 
 \helpref{wxObject}{wxobject}


@@ -34,7 +40,7 @@ each other.
 
 \membersection{wxEvtHandler::AddPendingEvent}\label{wxevthandleraddpendingevent}
 
 
 \membersection{wxEvtHandler::AddPendingEvent}\label{wxevthandleraddpendingevent}
 

-\func{virtual void}{AddPendingEvent}{\param{wxEvent\& }{event}}
+\func{void}{AddPendingEvent}{\param{wxEvent\& }{event}}

 
 This function posts an event to be processed later.
 
 
 This function posts an event to be processed later.
 


@@ -220,14 +226,14 @@ call \helpref{wxEvent::Skip}{wxeventskip}.
 
 \wxheading{Remarks}
 
 
 \wxheading{Remarks}
 

-Normally, your application would not call this function: it is called in the wxWindows
+Normally, your application would not call this function: it is called in the wxWidgets

 implementation to dispatch incoming user interface events to the framework (and application).
 
 However, you might need to call it if implementing new functionality (such as a new control) where
 you define new event types, as opposed to allowing the user to override virtual functions.
 
 An instance where you might actually override the {\bf ProcessEvent} function is where you want
 implementation to dispatch incoming user interface events to the framework (and application).
 
 However, you might need to call it if implementing new functionality (such as a new control) where
 you define new event types, as opposed to allowing the user to override virtual functions.
 
 An instance where you might actually override the {\bf ProcessEvent} function is where you want

-to direct event processing to event handlers not normally noticed by wxWindows. For example,
+to direct event processing to event handlers not normally noticed by wxWidgets. For example,

 in the document/view architecture, documents and views are potential event handlers.
 When an event reaches a frame, {\bf ProcessEvent} will need to be called on the associated
 document and view in case event handler functions are associated with these objects.
 in the document/view architecture, documents and views are potential event handlers.
 When an event reaches a frame, {\bf ProcessEvent} will need to be called on the associated
 document and view in case event handler functions are associated with these objects.