remove extra line breaks which prevents Doxygen from numbering list items correctly...

[wxWidgets.git] / docs / doxygen / overviews / eventhandling.h

diff --git a/docs/doxygen/overviews/eventhandling.h b/docs/doxygen/overviews/eventhandling.h
index 1edf26142b59cc105ef5be160bedbab91365f867..3ee135fc24bef9de6f1df682abc3178c610bcc08 100644 (file)
--- a/docs/doxygen/overviews/eventhandling.h
+++ b/docs/doxygen/overviews/eventhandling.h
@@ -128,7 +128,7 @@ the frame will result in calling OnSize() method. Note that this macro doesn't
 need a window identifier, since normally you are only interested in the current\r
 window's size events.\r
 \r
-The EVT_BUTTON macro demonstrates that the originating event does not have to\r
+The @c EVT_BUTTON macro demonstrates that the originating event does not have to\r
 come from the window class implementing the event table -- if the event source\r
 is a button within a panel within a frame, this will still work, because event\r
 tables are searched up through the hierarchy of windows for the command events.\r
@@ -184,7 +184,7 @@ in the previous section. However the similarities end here and both the syntax
 and the possibilities of handling events in this way are rather different.\r
 \r
 Let us start by looking at the syntax: the first obvious difference is that you\r
-need not use @c DECLARE_EVENT_TABLE() nor @c BEGIN_EVENT_TABLE and the\r
+need not use DECLARE_EVENT_TABLE() nor BEGIN_EVENT_TABLE() and the\r
 associated macros. Instead, in any place in your code, but usually in\r
 the code of the class defining the handler itself (and definitely not in the\r
 global scope as with the event tables), call its Connect() method like this:\r
@@ -331,10 +331,20 @@ doesn't count as having handled the event and the search continues):
     <li value="5">\r
     The event is passed to the next event handler, if any, in the event handler\r
     chain, i.e., the steps (1) to (4) are done for it. This chain can be formed\r
-    using wxEvtHandler::SetNextHandler() or wxWindow::PushEventHandler() but\r
-    usually there is no next event handler and chaining event handlers using\r
-    these functions is much less useful now that Connect() exists so this step\r
-    will almost never do anything.\r
+    using wxEvtHandler::SetNextHandler():\r
+        @image html overview_eventhandling_chain.png\r
+    (referring to the image, if @c A->ProcessEvent is called and it doesn't handle\r
+     the event, @c B->ProcessEvent will be called and so on...).\r
+    In the case of wxWindow you can build a stack (implemented using wxEvtHandler\r
+    double-linked list) using wxWindow::PushEventHandler():\r
+        @image html overview_eventhandling_winstack.png\r
+    (referring to the image, if @c W->ProcessEvent is called, it immediately calls\r
+     @c A->ProcessEvent; if nor @c A nor @c B handle the event, then the wxWindow\r
+     itself is used - i.e. the dynamically connected event handlers and static\r
+     event table entries of wxWindow are looked as the last possibility, after\r
+     all pushed event handlers were tested).\r
+    Note however that usually there are no wxEvtHandler chains nor wxWindows stacks\r
+    so this step will usually do anything.\r
     </li>\r
 \r
     <li value="6">\r
@@ -349,7 +359,7 @@ doesn't count as having handled the event and the search continues):
 \r
     <li value="7">\r
     Finally, i.e., if the event is still not processed, the wxApp object itself\r
-    gets a last chance to process it.\r
+    (which derives from wxEvtHandler) gets a last chance to process it.\r
     </li>\r
 </ol>\r
 \r