August 13th Monday (八月 十三日 月曜日）

  I am going to write my diary in Japanese and English at once.  I don't know whether it is an interesting.
Perhaps it is so chaotic.

  My house is still in air.  I hoped that all things is right.  If I have hands full, I will make mistakes
again.  As matter of a fact, I almost ignore a detail in my house contract.  It might be a deadly problem
in the future.

  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 (wxEvent::ShouldPropagate) (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.