commit remaining portions of #10087

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

diff --git a/docs/doxygen/overviews/eventhandling.h b/docs/doxygen/overviews/eventhandling.h
index bcafcadddcaeb4f0b52cdae811e07e07499dfc0c..1edf26142b59cc105ef5be160bedbab91365f867 100644 (file)
--- a/docs/doxygen/overviews/eventhandling.h
+++ b/docs/doxygen/overviews/eventhandling.h
@@ -182,7 +182,7 @@ handle the events first and, as before, this class must derive from
 wxEvtHandler (usually indirectly via wxWindow). See the declaration of MyFrame\r
 in the previous section. However the similarities end here and both the syntax\r
 and the possibilities of handling events in this way are rather different.\r
- \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
 associated macros. Instead, in any place in your code, but usually in\r
@@ -524,44 +524,44 @@ uniquely determine window identity in the event system (though you can use it
 for other purposes). In fact, identifiers do not need to be unique\r
 across your entire application as long they are unique within the\r
 particular context you're interested in, such as a frame and its children. You\r
-may use the @c wxID_OK identifier, for example, on any number of dialogs so\r
-long as you don't have several within the same dialog.\r
+may use the @c wxID_OK identifier, for example, on any number of dialogs\r
+as long as you don't have several within the same dialog.\r
 \r
 If you pass @c wxID_ANY to a window constructor, an identifier will be\r
 generated for you automatically by wxWidgets. This is useful when you don't\r
 care about the exact identifier either because you're not going to process the\r
-events from the control being created at all or because you process the events\r
+events from the control being created or because you process the events\r
 from all controls in one place (in which case you should specify @c wxID_ANY\r
 in the event table or wxEvtHandler::Connect call\r
-as well. The automatically generated identifiers are always negative and so\r
+as well). The automatically generated identifiers are always negative and so\r
 will never conflict with the user-specified identifiers which must be always\r
 positive.\r
 \r
 See @ref page_stdevtid for the list of standard identifiers available.\r
 You can use wxID_HIGHEST to determine the number above which it is safe to\r
 define your own identifiers. Or, you can use identifiers below wxID_LOWEST.\r
-Finally, you can allocate identifiers dynamically using wxNewId() function to.\r
+Finally, you can allocate identifiers dynamically using wxNewId() function too.\r
 If you use wxNewId() consistently in your application, you can be sure that\r
-the your identifiers don't conflict accidentally.\r
+your identifiers don't conflict accidentally.\r
 \r
 \r
 @section overview_eventhandling_custom Custom Event Summary\r
 \r
 @subsection overview_eventhandling_custom_general General approach\r
 \r
-Since version 2.2.x of wxWidgets, each event type is identified by ID which\r
-is given to the event type @e at runtime which makes it possible to add\r
+Since version 2.2.x of wxWidgets, each event type is identified by an ID\r
+given to the event type @e at runtime that makes it possible to add\r
 new event types to the library or application without risking ID clashes\r
 (two different event types mistakingly getting the same event ID).\r
 This event type ID is stored in a struct of type <b>const wxEventType</b>.\r
 \r
 In order to define a new event type, there are principally two choices.\r
-One is to define a entirely new event class (typically deriving from\r
+One is to define an entirely new event class (typically deriving from\r
 wxEvent or wxCommandEvent).\r
 \r
-The other is to use the existing event classes and give them an new event\r
-type. You'll have to define and declare a new event type using either way,\r
-and this is done using the following macros:\r
+The other is to use the existing event classes and give them a new event\r
+type. You'll have to define and declare a new event type either way\r
+using the following macros:\r
 \r
 @code\r
 // in the header of the source file\r
@@ -577,7 +577,7 @@ defining and working with the custom event types.
 \r
 @subsection overview_eventhandling_custom_existing Using Existing Event Classes\r
 \r
-If you just want to use a wxCommandEvent with a new event type, you can then use\r
+If you just want to use a wxCommandEvent with a new event type, use\r
 one of the generic event table macros listed below, without having to define a\r
 new event class yourself. This also has the advantage that you won't have to define a\r
 new wxEvent::Clone() method for posting events between threads etc.\r
@@ -719,11 +719,11 @@ For the full list of event classes, please see the
 @ref group_class_events "event classes group page".\r
 \r
 \r
-@todo for all controls state clearly when calling a member function results in an\r
-      event being generated and when it doesn't (possibly updating also the\r
-      'Events generated by the user vs programmatically generated events' paragraph\r
-      of the 'Event handling overview' with the list of the functions which break\r
-      that rule).\r
+@todo For all controls, state clearly when calling a member function results in\r
+      an event being generated and when it doesn't (possibly updating also the\r
+      'Events generated by the user versus programmatically-generated events'\r
+      paragraph of the 'Event Handling Overview' with the list of the functions\r
+      that break the rule).\r
 \r
 */\r
 \r