X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/dc28cdf8d4d895e953d1710bbf77a065106ff98f..8c6791e43ca1adb11db20674a2327dc5e354f629:/docs/doxygen/overviews/eventhandling.h

diff --git a/docs/doxygen/overviews/eventhandling.h b/docs/doxygen/overviews/eventhandling.h
index e504d6e5d1..3a0b0d9155 100644
--- a/docs/doxygen/overviews/eventhandling.h
+++ b/docs/doxygen/overviews/eventhandling.h
@@ -99,7 +99,7 @@ connect the events to the handlers dynamically, during run-time. See the
 
 
 
-@section overview_eventhandling_processing How events are processed
+@section overview_eventhandling_processing How Events are Processed
 
 When an event is received from the windowing system, wxWidgets calls
 wxEvtHandler::ProcessEvent on the first
@@ -228,7 +228,7 @@ will have to be written that will override ProcessEvent() in order to pass
 all events (or any selection of them) to the parent window.
 
 
-@section overview_eventhandling_prog Events generated by the user vs programmatically generated events
+@section overview_eventhandling_prog User Generated Events vs Programmatically Generated Events
 
 While generically wxEvents can be generated both by user
 actions (e.g. resize of a wxWindow) and by calls to functions
@@ -251,7 +251,7 @@ equivalents.
 
 
 
-@section overview_eventhandling_pluggable Pluggable event handlers
+@section overview_eventhandling_pluggable Pluggable Event Handlers
 
 In fact, you don't have to derive a new class from a window class
 if you don't want to. You can derive a new class from wxEvtHandler instead,
@@ -283,7 +283,7 @@ range of events independently from the other handlers.
 
 
 
-@section overview_eventhandling_winid Window identifiers
+@section overview_eventhandling_winid Window Identifiers
 
 Window identifiers are integers, and are used to
 uniquely determine window identity in the event system (though you can use it
@@ -311,7 +311,7 @@ If you use wxNewId() consistently in your application, you can be sure that
 the your identifiers don't conflict accidentally.
 
 
-@section overview_eventhandling_custom Custom event summary
+@section overview_eventhandling_custom Custom Event Summary
 
 @subsection overview_eventhandling_custom_general General approach
 
@@ -346,7 +346,7 @@ See also the @ref page_samples_event for an example of code
 defining and working with the custom event types.
 
 
-@subsection overview_eventhandling_custom_existing Using existing event classes
+@subsection overview_eventhandling_custom_existing Using Existing Event Classes
 
 If you just want to use a wxCommandEvent with
 a new event type, you can then use one of the generic event table macros
@@ -388,7 +388,7 @@ void MyWindow::SendEvent()
 @endcode
 
 
-@subsection overview_eventhandling_custom_generic Generic event table macros
+@subsection overview_eventhandling_custom_generic Generic Event Table Macros
 
 @beginTable
 @row2col{EVT_CUSTOM(event\, id\, func),
@@ -412,7 +412,7 @@ void MyWindow::SendEvent()
 @endTable
 
 
-@subsection overview_eventhandling_custom_ownclass Defining your own event class
+@subsection overview_eventhandling_custom_ownclass Defining Your Own Event Class
 
 Under certain circumstances, it will be required to define your own event
 class e.g. for sending more complex data from one place to another. Apart
@@ -480,12 +480,17 @@ void MyWindow::SendEvent()
 @endcode
 
 
+@section overview_eventhandling_macros Event Handling Summary
 
+For the full list of event classes, please see the
+@ref group_class_events "event classes group page".
 
-@section overview_eventhandling_macros Event macros summary
 
-For the full list of event classes, please see the
-@ref page_class_cat_events page.
+@todo for all controls state clearly when calling a member function results in an 
+      event being generated and when it doesn't (possibly updating also the 
+      'Events generated by the user vs programmatically generated events' paragraph 
+      of the 'Event handling overview' with the list of the functions which break 
+      that rule).
 
 */