Does anyone know why menu items don't have a Bind() method.
Because menus don't descend from wx.Window, where Bind() is defined.
I find myself doing this:
item = file_menu.Append(-1, "&Close","Close this frame")
self.Bind(wx.EVT_MENU, self.OnQuit, item)
Where self is a wx.Frame, most likely. Yes, this is what I do, too.
when it would be more natural to do:
item = file_menu.Append(-1, "&Close","Close this frame")
item.Bind(wx.EVT_MENU, self.OnQuit)
I don't believe that individual menu items stay in memory in the same way that windows do, so they don't participate in the normal event handling loop. So, when a menu item is selected, the menu will emit the event along with the id of the menu item - but you'll never get an object reference to the menu item, just the menu. At least that is how I understand it, and my understanding comes from observation mostly.
or, indeed, how many events are there for a menu?
item.Bind(self.OnQuit)
Aren't there activation events, check/uncheck events, and the like?
Does anyone know why menu items don't have a Bind() method.
Because menus don't descend from wx.Window, where Bind() is defined.
yes, but I was wondering why it couldn't be added
I don't believe that individual menu items stay in memory in the same way that windows do, so they don't participate in the normal event handling loop.
Which might be why it couldn't be added, though I would think one could have Bind() essentially be an alias for the same event binding that goes on otherwise.
or, indeed, how many events are there for a menu?
item.Bind(self.OnQuit)
Aren't there activation events, check/uncheck events, and the like?
well duh. just shows how hard I've thought about it. However, it seems like many widgets, like menus and buttons have a "most of the time" case. It would be nice if you could just specify the callback in the constructor.
Well fantasies aside, a MenuItem.Bind() would be nice.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
or, indeed, how many events are there for a menu?
item.Bind(self.OnQuit)
Aren't there activation events, check/uncheck events, and the like?
well duh. just shows how hard I've thought about it. However, it seems like many widgets, like menus and buttons have a "most of the time" case. It would be nice if you could just specify the callback in the constructor.
I agree completely with that sentiment - that most objects have a 'most of the time' event that is associated with it. EVT_TIMER for wx.Timer, EVT_CHECKBOX for wx.Checkbox, EVT_BUTTON for wx.Button, and EVT_MENU for wx.MenuItem, etc.
In Dabo, where we settled on implementing our own event handling system, we give that 'most of the time' event a name: Hit. So you'll see Dabo code like:
self.bindEvent(dabo.dEvents.Hit, self.onHit)
and out of context, you can't tell if the above line is in a timer, checkbox, menu item, or whatever. So for the 'most of the time' cases, the programmer just needs to remember one event name instead of many.
Does anyone know why menu items don't have a Bind() method.
The most important reason is that menu events are not delivered to the menu item, so even if the item had a Bind there would be no way for it to call the handler because item object would never see the event.
Depending on how the menu is used and the platform, the events may not even be delivered to the wx.Menu, which is where it makes sense to some folks to do the Bind. (Although there was some discussion some months back about making all of the platforms deliver to the menu itself first, and then the parent window, but it hasn't been done yet AFAIK.)
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Does anyone know why menu items don't have a Bind() method.
The most important reason is that menu events are not delivered to the menu item, so even if the item had a Bind there would be no way for it to call the handler because item object would never see the event.
Depending on how the menu is used and the platform, the events may not even be delivered to the wx.Menu, which is where it makes sense to some folks to do the Bind. (Although there was some discussion some months back about making all of the platforms deliver to the menu itself first, and then the parent window, but it hasn't been done yet AFAIK.)
OK, I have a better idea of it now, but I'm still wondering if a MenuItem.Bind() method could be created that hides what's going on. Where the events actually get delivered is an implementation detail, that won't be important, most of the time. Is there any way to find out, within a wx.MenuItem, what Frame it is on? If so, you could do something like this:
OK, I have a better idea of it now, but I'm still wondering if a MenuItem.Bind() method could be created that hides what's going on. Where the events actually get delivered is an implementation detail, that won't be important, most of the time. Is there any way to find out, within a wx.MenuItem, what Frame it is on?
No, the wx.MenuItem may not be attached to a menu or menubar yet when Bind is called. It may not *ever* be attached to a menubar (and therefore a frame) if the menu is to be used with PopupMenu.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
No, the wx.MenuItem may not be attached to a menu or menubar yet when Bind is called. It may not *ever* be attached to a menubar (and therefore a frame) if the menu is to be used with PopupMenu.
Hmm. this is clearly uglier than I thought at first. I'll drop it now! Thanks for the explanation
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception