X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/265accbe551ec481a3270b220933a0e99596fb7c..5814e8ba4e57839acd1eb7491ed392b07e382593:/docs/latex/wx/tevent.tex diff --git a/docs/latex/wx/tevent.tex b/docs/latex/wx/tevent.tex index 0d0ae34d0b..e747b06714 100644 --- a/docs/latex/wx/tevent.tex +++ b/docs/latex/wx/tevent.tex @@ -211,7 +211,6 @@ here is a list of system events which will NOT get sent to the parent's event ha \twocolitem{\helpref{wxSizeEvent}{wxsizeevent}}{A size event} \twocolitem{\helpref{wxScrollWinEvent}{wxscrollwinevent}}{A scroll event sent by a scrolled window (not a scroll bar)} \twocolitem{\helpref{wxSysColourChangedEvent}{wxsyscolourchangedevent}}{A system colour change event} -\twocolitem{\helpref{wxUpdateUIEvent}{wxupdateuievent}}{A user interface update event} \end{twocollist} In some cases, it might be desired by the programmer to get a certain number @@ -220,6 +219,30 @@ 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. + +\subsection{Events generated by the user vs programmatically generated events}\label{progevent} + +While generically \helpref{wxEvents}{wxevent} can be generated both by user +actions (e.g. resize of a \helpref{wxWindow}{wxwindow}) and by calls to functions +(e.g. \helpref{wxWindow::SetSize}{wxwindowsetsize}), wxWidgets controls +normally send \helpref{wxCommandEvent}{wxcommandevent}-derived events only for +the user-generated events. The only {\bf exceptions} to this rule are: + +\begin{twocollist}\itemsep=0pt +\twocolitem{\helpref{wxNotebook::AddPage}{wxnotebookaddpage}}{No event-free alternatives} +\twocolitem{\helpref{wxNotebook::AdvanceSelection}{wxnotebookadvanceselection}}{No event-free alternatives} +\twocolitem{\helpref{wxNotebook::DeletePage}{wxnotebookdeletepage}}{No event-free alternatives} +\twocolitem{\helpref{wxNotebook::SetSelection}{wxnotebooksetselection}}{Use \helpref{wxNotebook::ChangeSelection}{wxnotebookchangeselection} instead, as \helpref{wxNotebook::SetSelection}{wxnotebooksetselection} is deprecated} +\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 +of \helpref{wxTextCtrl::SetValue}{wxtextctrlsetvalue} but the other functions, +such as \helpref{Replace}{wxtextctrlreplace} or \helpref{WriteText}{wxtextctrlwritetext} +don't have event-free equivalents} +\end{twocollist} + + % VZ: it doesn't work like this, but just in case we ever reenable this % behaviour, I leave it here % @@ -245,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 @@ -417,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 @@ -447,7 +476,7 @@ DEFINE_EVENT_TYPE(wxEVT_MY_EVENT) BEGIN_EVENT_TABLE(MyFrame, wxFrame) EVT_MENU (wxID_EXIT, MyFrame::OnExit) // .... - EVT_COMMAND (wxEVT_MY_EVENT, ID_MY_WINDOW, MyFrame::OnMyEvent) + EVT_COMMAND (ID_MY_WINDOW, wxEVT_MY_EVENT, MyFrame::OnMyEvent) END_EVENT_TABLE() void MyFrame::OnMyEvent( wxCommandEvent &event ) @@ -485,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}