July 27th Monday (七月 二十七日 月曜日)

The normal order of event table searching by ProcessEvent is as follows:

   1. If the object is disabled (via a call to wxEvtHandler::SetEvtHandlerEnabled) the function skips to step (6).
   2. If the object is a wxWindow, ProcessEvent is recursively called on the window's wxValidator. If this returns true, the function
      exits.
   3. SearchEventTable is called for this event handler. If this fails, the base class table is tried, and so on until no more tables
      exist or an appropriate function was found, in which case the function exits.
   4. The search is applied down the entire chain of event handlers (usually the chain has a length of one). If this succeeds, the function
      exits.
   5. If the object is a wxWindow and the event is set to set to propagate (in the library only wxCommandEvent based events are set to
      propagate), ProcessEvent is recursively applied to the parent window's event handler. If this returns true, the function exits.
   6. Finally, ProcessEvent is called on the wxApp object.

  Pay close attention to Step 5. People often overlook or get confused by this powerful feature of the wxWidgets event processing system.
To put it a different way, events set to propagate (most likely derived either directly or indirectly from wxCommandEvent) will travel up
the containment hierarchy from child to parent until the maximal propagation level is reached or an event handler is found that doesn't
call event.Skip().

  Finally, there is another additional complication (which, in fact, simplifies life of wxWidgets programmers significantly): when propagating
the command events upwards to the parent window, the event propagation stops when it reaches the parent dialog, if any. This means that
you don't risk to get unexpected events from the dialog controls (which might be left unprocessed by the dialog itself because it doesn't
care about them) when a modal dialog is popped up.  The events do propagate beyond the frames, however.  The rationale for this choice is that
there are only a few frames in a typical application and their parent-child relation are well understood by the programmer while it may be
very difficult, if not impossible, to track down all the dialogs which may be popped up in a complex program (remember that some are created
automatically by wxWidgets).  If you need to specify a different behaviour for some reason, you can use SetExtraStyle(wxWS_EX_BLOCK_EVENTS)
explicitly to prevent the events from being propagated beyond the given window or unset this flag for the dialogs which have it on by default.

  Typically events that deal with a window as a window (size, motion, paint, mouse, keyboard, etc.) are sent only to the window.  Events that
have a higher level of meaning and/or are generated by the window itself, (button click, menu select, tree expand, etc.) are command events
and are sent up to the parent to see if it is interested in the event.