+@subsection overview_events_nexthandler Event Handlers Chain
+
+The step 4 of the event propagation algorithm checks for the next handler in
+the event handler chain. This chain can be formed using
+wxEvtHandler::SetNextHandler():
+ @image html overview_events_chain.png
+(referring to the image, if @c A->ProcessEvent is called and it doesn't handle
+ the event, @c B->ProcessEvent will be called and so on...).
+
+Additionally, in the case of wxWindow you can build a stack (implemented using
+wxEvtHandler double-linked list) using wxWindow::PushEventHandler():
+ @image html overview_events_winstack.png
+(referring to the image, if @c W->ProcessEvent is called, it immediately calls
+ @c A->ProcessEvent; if nor @c A nor @c B handle the event, then the wxWindow
+itself is used -- i.e. the dynamically bind event handlers and static event
+table entries of wxWindow are looked as the last possibility, after all pushed
+event handlers were tested).
+
+By default the chain is empty, i.e. there is no next handler.
+
+
+@section overview_events_custom Custom Event Summary
+
+@subsection overview_events_custom_general General approach
+
+As each event is uniquely defined by its event type, defining a custom event
+starts with defining a new event type for it. This is done using
+wxDEFINE_EVENT() macro. As an event type is a variable, it can also be
+declared using wxDECLARE_EVENT() if necessary.
+
+The next thing to do is to decide whether you need to define a custom event
+class for events of this type or if you can reuse an existing class, typically
+either wxEvent (which doesn't provide any extra information) or wxCommandEvent
+(which contains several extra fields and also propagates upwards by default).
+Both strategies are described in details below. See also the @ref
+page_samples_event for a complete example of code defining and working with the
+custom event types.
+
+
+@subsection overview_events_custom_existing Using Existing Event Classes
+
+If you just want to use a wxCommandEvent with a new event type, use one of the
+generic event table macros listed below, without having to define a new event
+class yourself.
+
+Example:
+
+@code
+// this is typically in a header: it just declares MY_EVENT event type
+wxDECLARE_EVENT(MY_EVENT, wxCommandEvent);
+
+// this is a definition so can't be in a header
+wxDEFINE_EVENT(MY_EVENT, wxCommandEvent);
+
+// example of code handling the event with event tables
+BEGIN_EVENT_TABLE(MyFrame, wxFrame)
+ EVT_MENU (wxID_EXIT, MyFrame::OnExit)
+ ...
+ EVT_COMMAND (ID_MY_WINDOW, MY_EVENT, MyFrame::OnMyEvent)
+END_EVENT_TABLE()
+
+void MyFrame::OnMyEvent(wxCommandEvent& event)
+{
+ // do something
+ wxString text = event.GetText();
+}
+
+// example of code handling the event with Bind<>():
+MyFrame::MyFrame()
+{
+ Bind(MY_EVENT, &MyFrame::OnMyEvent, this, ID_MY_WINDOW);
+}
+
+// example of code generating the event
+void MyWindow::SendEvent()
+{
+ wxCommandEvent event(MY_EVENT, GetId());
+ event.SetEventObject(this);
+
+ // Give it some contents
+ event.SetText("Hello");
+
+ // Do send it
+ ProcessWindowEvent(event);
+}
+@endcode
+
+
+@subsection overview_events_custom_ownclass Defining Your Own Event Class
+
+Under certain circumstances, you must define your own event class e.g., for
+sending more complex data from one place to another. Apart from defining your
+event class, you also need to define your own event table macro if you want to
+use event tables for handling events of this type.
+
+Here is an example:
+
+@code
+// define a new event class
+class MyPlotEvent: public wxEvent
+{
+public:
+ MyPlotEvent(wxEventType eventType, int winid, const wxPoint& pos)
+ : wxEvent(winid, eventType),
+ m_pos(pos)
+ {
+ }
+
+ // accessors
+ wxPoint GetPoint() const { return m_pos; }
+
+ // implement the base class pure virtual
+ virtual wxEvent *Clone() const { return new MyPlotEvent(*this); }
+
+private:
+ const wxPoint m_pos;
+};
+
+// we define a single MY_PLOT_CLICKED event type associated with the class
+// above but typically you are going to have more than one event type, e.g. you
+// could also have MY_PLOT_ZOOMED or MY_PLOT_PANNED &c -- in which case you
+// would just add more similar lines here
+wxDEFINE_EVENT(MY_PLOT_CLICKED, MyPlotEvent);
+
+
+// if you want to support old compilers you need to use some ugly macros:
+typedef void (wxEvtHandler::*MyPlotEventFunction)(MyPlotEvent&);
+#define MyPlotEventHandler(func) wxEVENT_HANDLER_CAST(MyPlotEventFunction, func)
+
+// if your code is only built using reasonably modern compilers, you could just
+// do this instead:
+#define MyPlotEventHandler(func) (&func)
+
+// finally define a macro for creating the event table entries for the new
+// event type
+//
+// remember that you don't need this at all if you only use Bind<>() and that
+// you can replace MyPlotEventHandler(func) with just &func unless you use a
+// really old compiler
+#define MY_EVT_PLOT_CLICK(id, func) \
+ wx__DECLARE_EVT1(MY_PLOT_CLICKED, id, MyPlotEventHandler(func))
+
+
+// example of code handling the event (you will use one of these methods, not
+// both, of course):
+BEGIN_EVENT_TABLE(MyFrame, wxFrame)
+ EVT_PLOT(ID_MY_WINDOW, MyFrame::OnPlot)
+END_EVENT_TABLE()
+
+MyFrame::MyFrame()
+{
+ Bind(MY_PLOT_CLICKED, &MyFrame::OnPlot, this, ID_MY_WINDOW);
+}
+
+void MyFrame::OnPlot(MyPlotEvent& event)
+{
+ ... do something with event.GetPoint() ...
+}
+
+
+// example of code generating the event:
+void MyWindow::SendEvent()
+{
+ MyPlotEvent event(MY_PLOT_CLICKED, GetId(), wxPoint(...));
+ event.SetEventObject(this);
+ ProcessWindowEvent(event);
+}
+@endcode
+
+
+
+@section overview_events_misc Miscellaneous Notes
+
+@subsection overview_events_virtual Event Handlers vs Virtual Methods
+
+It may be noted that wxWidgets' event processing system implements something
+close to virtual methods in normal C++ in spirit: both of these mechanisms
+allow you to alter the behaviour of the base class by defining the event handling
+functions in the derived classes.
+
+There is however an important difference between the two mechanisms when you
+want to invoke the default behaviour, as implemented by the base class, from a
+derived class handler. With the virtual functions, you need to call the base
+class function directly and you can do it either in the beginning of the
+derived class handler function (to post-process the event) or at its end (to
+pre-process the event). With the event handlers, you only have the option of
+pre-processing the events and in order to still let the default behaviour
+happen you must call wxEvent::Skip() and @em not call the base class event
+handler directly. In fact, the event handler probably doesn't even exist in the
+base class as the default behaviour is often implemented in platform-specific
+code by the underlying toolkit or OS itself. But even if it does exist at
+wxWidgets level, it should never be called directly as the event handlers are
+not part of wxWidgets API and should never be called directly.
+
+
+
+@subsection overview_events_prog User Generated Events vs Programmatically Generated Events
projects / wxWidgets.git / blobdiff