Re[2]: [lmi] Overriding wx member functions

[Vadim Zeitlin]

On Thu, 13 Apr 2006 04:55:26 +0000 Greg Chicares <address@hidden> wrote:

GC> Do I correctly understand that, as a general principle, you'd say that most
GC> EVT_CHILD_FOCUS handlers should usually call event.Skip()?

 Yes, calling Skip() would allow any parent windows interested in child
focus change to also process the event. Not calling it would mean that no
windows beyond this one (handling the event) are going to get this event.

GC> I'd also like to ask about using Skip() in a EVT_NOTEBOOK_PAGE_CHANGING
GC> handler that conditionally vetoes the event. This scares me:
GC> 
GC> http://www.wxwidgets.org/wiki/index.php/Events#Event.Skip_and_Event.Veto
GC> |
GC> | I've never seen it done, but Skip and Veto could be combined. You could
GC> | catch a notification event, Veto it, then call Skip giving the parent
GC> | classes or windows a chance to unVeto it.
GC> |
GC> | (It appears in wxWidgets 2.6.1 that calling Skip() after Veto() on an
GC> | event causes the Veto() to be ignored...)

 FWIW, I can confirm that the above is correct.

GC> While trying to formulate a general rule, which I think should be
GC> something like this...
GC> 
GC>   if event handler takes a wxCommandEvent argument
GC>     then don't call Skip() (or explain reason for not obeying this rule)
GC>   else
GC>     then  do   call Skip() (or explain reason for not obeying this rule)

 I think the real test in the "if" should be "event can be handled by more
than one handler". It's true that usually wxCommandEvents are handled in
one place only and others might be processed in multiple places. But there
are exceptions, such as wxEVT_PAINT (non command event which must be
processed exactly once and so should never be skipped) or wxEVT_CHILD_FOCUS
(command event which it makes sense to handle in more than one place).

GC> ...I'm trying to decide where it's best to place the call to Skip().
GC> Now, as I understand it, Skip() really just sets a flag that's acted on
GC> after my event handler exits, so it doesn't matter whether I call it at
GC> the beginning or at the end of my handler...

 Absolutely.

GC> ...so I'm thinking it's wiser always to call Skip() on the first line,
GC> if I call it at all.

 I agree.


GC> But now I wonder about this EVT_NOTEBOOK_PAGE_CHANGING handler:
GC> 
GC>   event.Skip(); // First line: call Skip() once and only once.
GC> 
GC>   if(should_exit_early)
GC>     return; // Skipped.
GC> 
GC>   if(should_veto)
GC>     {
GC>     event.Veto();
GC>     return; // VETO AND SKIP: SEEMS TO BE A PROBLEM
GC>     }
GC> 
GC>   // Normal non-veto processing here; event skipped.
GC> 
GC> When the wiki says (of wx-2.6.1, at least) that
GC> | calling Skip() after Veto()...causes the Veto() to be ignored is
GC> that regarded as a defect, or a feature?

 A feature. If an event is skipped, it's not taken into account. As the
quote above says, it might make sense in some very special cases to use
both Skip() and Veto() but I've never had any need to do it and I'd try
to avoid it even if I had because it's really not obvious. So just call
event.Skip(false) above (to unset the flag) or make an exception to the
rule of always doing Skip() as the first thing in the function if there
is a possibility that event is going to be vetoed.

 Or you could decide to not Skip() it at all in this particular case as
it seems unlikely that you need to react to this event anywhere else
anyhow.

GC> But if I write
GC> 
GC>   event.Skip(); // First line: call Skip() once and only once.
GC>   ...
GC>   if(should_veto)
GC>     {
GC>     event.Skip(false); // CANCEL THE PRECEDING SKIP
GC>     event.Veto();
GC>     return;
GC>     }
GC> 
GC> then it seems to work. Is this likely to prove reliable across wx
GC> versions?

 Yes, this will definitely work.

 Please let me know if I didn't answer any of your questions,
VZ