Re: [lmi] Overriding wx member functions

[Greg Chicares]

On 2005-11-27 14:58 UTC, Vadim Zeitlin wrote:
> On Sat, 26 Nov 2005 23:40:47 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> 2. I noticed that the OnChildFocus() handler in 'xml_notebook.cpp'
> 
>  This is however quite different: OnChildFocus() is not a virtual function
> but a (non virtual) event handler. Event handlers can never call the base
> class event handler. All they can do is to call event.Skip() to let wx do
> it automatically. And the rule here is clear: if you are sure that you
> did everything necessary to process a given event, then don't call it. If
> you are not, then do. For the command events (button clicks, menu commands
> and so on) and update UI events you almost never want to call event.Skip()
> as there should be exactly one handler for them. For most of the others you
> almost always should skip the event.

I don't wish to seem dense, but I'll risk that in order to get things right.
Do I correctly understand that, as a general principle, you'd say that most
EVT_CHILD_FOCUS handlers should usually call event.Skip()?

I've tried carefully to follow this guidance, or write a comment giving an
explicit reason for not doing so, everywhere...except, it would seem in the
EVT_CHILD_FOCUS handler that I had specifically asked about. I don't see any
reason not to call Skip() there. Adding it does no harm that I have been
able to detect. I'm thinking this is just a weird oversight on my part.

I'd also like to ask about using Skip() in a EVT_NOTEBOOK_PAGE_CHANGING
handler that conditionally vetoes the event. This scares me:

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

Let me explain how I reach my question.

While trying to formulate a general rule, which I think should be
something like this...

  if event handler takes a wxCommandEvent argument
    then don't call Skip() (or explain reason for not obeying this rule)
  else
    then  do   call Skip() (or explain reason for not obeying this rule)

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

...and I often write early-exit code at the top of functions, so I want
to avoid mistakes like

  if(should_exit_early_0)
    return event.Skip();

  else if(should_exit_early_1)
    return; // OOPS, FORGOT TO CALL Skip()

  else
    ...
    event.Skip();

...so I'm thinking it's wiser always to call Skip() on the first line,
if I call it at all. While that may seem unusual, it could encourage
maintainers who might not understand wx deeply to stop and wonder, and
maybe search this list's archives--so it's not necessarily a bad thing.

But now I wonder about this EVT_NOTEBOOK_PAGE_CHANGING handler:

  event.Skip(); // First line: call Skip() once and only once.

  if(should_exit_early)
    return; // Skipped.

  if(should_veto)
    {
    event.Veto();
    return; // VETO AND SKIP: SEEMS TO BE A PROBLEM
    }

  // Normal non-veto processing here; event skipped.

When the wiki says (of wx-2.6.1, at least) that
| calling Skip() after Veto()...causes the Veto() to be ignored is
that regarded as a defect, or a feature? Perhaps it's intentional,
because I observe that problem in 2.7 (wx20060323 snapshot)--thank
goodness for automated GUI unit tests that show that immediately.

But if I write

  event.Skip(); // First line: call Skip() once and only once.
  ...
  if(should_veto)
    {
    event.Skip(false); // CANCEL THE PRECEDING SKIP
    event.Veto();
    return;
    }

then it seems to work. Is this likely to prove reliable across wx
versions?