no changes, just some markup fixes

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@55788 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

diff --git a/docs/doxygen/overviews/eventhandling.h b/docs/doxygen/overviews/eventhandling.h
index 5d7385cb1ea6191c77300c01514b2d519309a67c..9618a50ee0eb9569d1be277edc0e45d8b353e64e 100644 (file)
--- a/docs/doxygen/overviews/eventhandling.h
+++ b/docs/doxygen/overviews/eventhandling.h
@@ -272,11 +272,12 @@ Now let us describe the semantic differences:
                                NULL,  // unused extra data parameter\r
                                this); // this indicates the object to connect to\r
             }\r
                                NULL,  // unused extra data parameter\r
                                this); // this indicates the object to connect to\r
             }\r

-        @endcode will work exactly as expected. Note that you can get the\r
-        object which generated the event -- and which is not the same as the\r
-        frame -- via wxEvent::GetEventObject() method of @c event argument\r
-        passed to the event handler.\r
-    <li>\r
+        @endcode\r
+        will work exactly as expected. Note that you can get the object which\r
+        generated the event -- and which is not the same as the frame -- via\r
+        wxEvent::GetEventObject() method of @c event argument passed to the\r
+        event handler.\r
+    </li>\r

 </ul>\r
 \r
 To summarize, using Connect() requires slightly more typing but is much more\r
 </ul>\r
 \r
 To summarize, using Connect() requires slightly more typing but is much more\r


@@ -296,7 +297,7 @@ wxEvtHandler::ProcessEvent() on the first event handler object belonging to the
 window generating the event. The normal order of event table searching by\r
 ProcessEvent() is as follows, with the event processing stopping as soon as a\r
 handler is found (unless the handler calls wxEvent::Skip() in which case it\r
 window generating the event. The normal order of event table searching by\r
 ProcessEvent() is as follows, with the event processing stopping as soon as a\r
 handler is found (unless the handler calls wxEvent::Skip() in which case it\r

-doesn't count as having handled the event):\r
+doesn't count as having handled the event and the search continues):\r

 <ol>\r
     <li value="0">\r
     Before anything else happens, wxApp::FilterEvent() is called. If it returns\r
 <ol>\r
     <li value="0">\r
     Before anything else happens, wxApp::FilterEvent() is called. If it returns\r


@@ -350,7 +351,7 @@ doesn't count as having handled the event):
     </li>\r
 </ol>\r
 \r
     </li>\r
 </ol>\r
 \r

-<em>Please pay close attention to step 6!</em>. People often overlook or get\r
+<em>Please pay close attention to step 6!</em> People often overlook or get\r

 confused by this powerful feature of the wxWidgets event processing system. The\r
 details of event propagation upwards the window hierarchy are described in the\r
 next section.\r
 confused by this powerful feature of the wxWidgets event processing system. The\r
 details of event propagation upwards the window hierarchy are described in the\r
 next section.\r