lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Overriding wx member functions


From: Vadim Zeitlin
Subject: Re: [lmi] Overriding wx member functions
Date: Sun, 27 Nov 2005 15:58:46 +0100

On Sat, 26 Nov 2005 23:40:47 +0000 Greg Chicares <address@hidden> wrote:

GC> 1. Is there any general rule that indicates whether the base-class
GC> member should be called explicitly in a derived-class override, and,
GC> if so, whether it should be called at the beginning of the overriding
GC> function or at the end?

 No, unfortunately not. You can only hope that it is mentioned in the
documentation or in the base class comments but even this is not always the
case. The usual -- but by no means 100% -- rule is that you do have to call
the base class virtual function.

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.

GC> doesn't call the base-class function of the same name, probably with
GC> the ultimate effect that wxControlContainer::SetLastFocus() doesn't
GC> get called. That seemed to be a possible explanation for this problem:

 Yes, it is quite possible. Please try adding event.Skip() to see if it
fixes the problem.

GC> 3. In 'xml_notebook.hpp' I've coded things like
GC>     void OnInitDialog            (wxInitDialogEvent&);
GC>     void OnOK                    (wxCommandEvent&   );
GC> in the hope that I'd be overriding base-class implementations (which
GC> I don't always invoke explicitly, but probably should), but it appears
GC> that I'm actually hiding the base-class versions because they're not
GC> virtual. Is there a reason for them not to be virtual?

 Yes, event handlers are never virtual because virtual functions dispatch
mechanism is not used for them so it would be only confusing (and slightly
wasteful but this is not a big problem).

GC> What practice is recommended in this case--to use a distinct name in
GC> the derived class? I'm wondering whether I should change all my 'On-'
GC> functions to use a different prefix, in order to avoid problems like
GC> this.

 There is no real problem in hiding the base class function but it's true
that we should avoid using such common names as OnInitDialog() in wx itself
and use InternalOnInitDialog() and so on instead. But, as I said, it's not
a problem at all if you use the same name in the derived class.

 Regards,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]