The wxEvent and wxCommandEvent classes have a very non-intuitive "feature" in that the order of their initialisation arguments is exactly reversed.
wxEvent.__init__( self, windowID, eventType )
vs.
wxPyCommandEvent.__init__( self, eventType, windowID )
I would strongly recommend including text in docs for both initialisers regarding the difference. (I just spent 3 hours tracking this down in my little app here, and it was only when I compared my auto-generated event classes to my sample in the wiki that I finally spotted the difference, no need for someone else to go through that... (It's hard to track down a problem like this, all you know is that the event disappears)).
Would also suggest that docs for event classes make clear distinctions between (short-form, full-form, storage in the classes, explanation):
windowID -- window identifier -- m_id -- ID of the generated window, as generated by wxNewId() and accessed via wxWindow.GetId()
eventTypeID -- event type identifier -- m_eventType -- type ID of the event-class, as generated by wxNewEventType()
selectionID -- selection identifier -- m_commandInt -- ID of selected sub-elements, the integers associated with menu items, toolbar items, or choice-indices
For instance (from the wxEvent docs):
"Returns the identifier associated with this event, such as a button command id."
Would seem to be saying "return the command ID", which could be either m_eventType (type-of-command), or m_commandInt (command integer associated with the event/command). It actually appears that GetId() returns m_id (windowID), i.e. the originating window's GetId().
Sure, I eventually figured that out, but for the longest time I was wondering why, when the event _said_ it's GetId() == the eventTypeID I had registered for the event, it wasn't getting to the event handler.
Enjoy yourselves,
Mike
···
_______________________________________
Mike C. Fletcher
Why, yes, I am looking for a job...
http://members.rogers.com/mcfletch/