the Mysterious Mouse

Robin, I'm very grateful for your careful explanations. I have studied them as others study Revelation, and yea, I begin to affirm that I am enlightened. Or on the track at least. I didn't see that non-command events don't propagate. And in the situation I was describing -- a mouse-click in an STC that's inside (is the child of) a Frame -- it's the native control, the library code for the STC class, that originally gets the click. If so, then I see why, when I try to bind the click in the frame (only), then *nobody* in my code apparently gets the click, because the library code has exhausted it. Is that right?

I notice that I accidentally said, and you incidentally confirmed, that two different classes can bind the same event. (The child STC binds its "own" mouse-click and acts on it; the parent Frame binds its child's mouse-click and acts on it in some other way.) That's interesting, and I don't remember seeing this in the documentation. I suppose there's no possibility of competition -- the event has just one "home", and we're just adding *extra* behaviors in response to it. Hm.

Charles Hartman
Professor of English, Poet in Residence
Connecticut College
http://cherry.conncoll.edu/cohar
http://villex.blogspot.com

Charles Hartman wrote:

Robin, I'm very grateful for your careful explanations. I have studied them as others study Revelation, and yea, I begin to affirm that I am enlightened. Or on the track at least. I didn't see that non-command events don't propagate. And in the situation I was describing -- a mouse-click in an STC that's inside (is the child of) a Frame -- it's the native control, the library code for the STC class, that originally gets the click. If so, then I see why, when I try to bind the click in the frame (only), then *nobody* in my code apparently gets the click, because the library code has exhausted it. Is that right?

It sends the event to the widget that the mouse click happens in, and since it is not a command event that is as far as it goes.

I notice that I accidentally said, and you incidentally confirmed, that two different classes can bind the same event. (The child STC binds its "own" mouse-click and acts on it; the parent Frame binds its child's mouse-click and acts on it in some other way.) That's interesting, and I don't remember seeing this in the documentation. I suppose there's no possibility of competition -- the event has just one "home", and we're just adding *extra* behaviors in response to it. Hm.

Correct, more or less. Multiple bindings of the same event happening in the same widgets are possible, because wxPython uses the dynamic event tables provided by wxWidgets[1]. Additionally, any callable object can be bound as the handler (as you did in your example by bindind an event in the child to a method of the parent) not just methods of the class receiving the event.

The last binding gets first crack at handling the event, if it calls Skip then the next-to-last gets called, etc. until all the bindings to that instance of the widget have been tried. Then if it is a command event (or has otherwise been set to propogate) the parent window will be searched for matching bindings. The first time a matching handler is called that doesn't call Skip then processing stops.

[1] As opposed to the static event tables that most of the C++ code uses. The dynamic event tables are associated with the instance of the window, and static event tables are associated with the class.

ยทยทยท

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!