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
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
</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