events and the inheritance hierarchy

wxPython Users
1

I’ve been trying to get my mind right on event handling, and I’m having a problem with the inheritance hierarchy.
Watching events propagate up the container hierarchy (e.g. button --> panel --> frame -->) presents no problems.
Can someone post an example where the path is e.g. button-sub-sub-class --> button-sub-class , and we can
watch the events propagate up?

I’m unsure that there are any practical consequences for me, but enquiring minds like to know.

thanks

2

I'm pretty sure the answer is no:

wx has multiple hierarchys -- which are quite independent. Event
propagation follows the parent-child hierarchy, NOT the super-sub
class hierachy. (and the sizer hierachy is a third, also irrelevent.

The thing to keep in mind is that at the wx level, a particular
wx.Window instance is only one thing -- regardless of whether it is
implemented as a sub-sub-sub-sub class of something -- there is still
only one Windows, and thus only one object to send the event to.

If you do want a super-class event handler to be called in a
sub-class, you can call it directly in the sub-class event handler.

HTH,
  -Chris

···

On Wed, Jun 12, 2013 at 5:37 PM, <jimmy@cs.cofc.edu> wrote:

I've been trying to get my mind right on event handling, and I'm having a
problem with the inheritance hierarchy.
Watching events propagate up the container hierarchy (e.g. button --> panel
--> frame -->) presents no problems.
Can someone post an example where the path is e.g. button-sub-sub-class -->
button-sub-class , and we can
watch the events propagate up?

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

3

Chris Barker - NOAA Federal wrote:

I've been trying to get my mind right on event handling, and I'm having a
problem with the inheritance hierarchy.
Watching events propagate up the container hierarchy (e.g. button --> panel
--> frame -->) presents no problems.
Can someone post an example where the path is e.g. button-sub-sub-class -->
button-sub-class , and we can
watch the events propagate up?

I'm pretty sure the answer is no:

wx has multiple hierarchys -- which are quite independent. Event
propagation follows the parent-child hierarchy, NOT the super-sub
class hierachy. (and the sizer hierachy is a third, also irrelevent.

The static event tables in C++ do flow up the class hierarchy before flowing up the containment hierarchy. This is because the event tables are associated with the class, so there is more than one table per instance and they all need to be searched when an event is being processed.

On the other hand, the dynamic event tables are associated with the instance, so there is only one of them per widget instead of many. However it is possible to simulate the behavior of the static event tables simply by calling Bind in each class. Although the event is being bound to the same instance more than one time, as long as the binding takes place in the right order (parent class Binds before child class) then it will appear that the processing of the events is flowing up the class hierarchy the same way that it does with the static event tables in C++.

···

On Wed, Jun 12, 2013 at 5:37 PM,<jimmy@cs.cofc.edu> wrote:

--
Robin Dunn
Software Craftsman

4

Does this mean inside the widget.init() it is better to put self.Binds() before self.widget = Widget(args)?

if I do:

class Frame(wx.Frame):

def init(self, *args):

self.widget = Widget(args)

self.Bind(blabla)

instead of:

self.Bind(blabla)

self.widget = Widget(args)

This would put the event Bind()s of the parent -after- the event Bind()s of the child control (presuming that self.Binds() are in the contol’s Widget.init())

5

Does this mean inside the widget.__init__() it is better to put self.Binds()
before self.widget = Widget(args)?

I don't think it makes any difference.

class Frame(wx.Frame):
    def __init__(self, *args):
        self.widget = Widget(args)
        self.Bind(blabla)
instead of:
        self.Bind(blabla)
        self.widget = Widget(args)

This would put the event Bind()s of the parent -after- the event Bind()s of
the child control (presuming that self.Binds() are in the contol's
Widget.__init__())

Bind() sets up the event binding -- but the dispatch is done at event
time -- if the event starts in the child, it will get processed there
first -- then move up to the parent (if it is a CommandEvent) and
event.Skip() was called.

So the order in which they were bound doesn't matter.

-Chris

···

On Tue, Jun 18, 2013 at 2:55 PM, Dev Player <devplayer@gmail.com> wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

6

Dev Player wrote:

Does this mean inside the widget.__init__() it is better to put
self.Binds() before self.widget = Widget(args)?

if I do:

class Frame(wx.Frame):
     def __init__(self, *args):
         self.widget = Widget(args)
         self.Bind(blabla)
instead of:
         self.Bind(blabla)
         self.widget = Widget(args)

This would put the event Bind()s of the parent -after- the event Bind()s
of the child control (presuming that self.Binds() are in the contol's
Widget.__init__())

My comment was about Binds in parent or base classes (the class hierarchy) not about parent/child windows (the containment hierarchy.)

···

--
Robin Dunn
Software Craftsman