Is anybody else having trouble with event.GetId() on OS X?
In wxPython 2.8.9.2, event.GetId() returned the ID of the control that
triggered the event on OS X, just like it does on Windows.
In wxPython 2.8.12.0 and 2.8.12.1, event.GetId() always returns 0 on OS X.
It still works correctly on Windows in wxPython 2.8.12.0.
I was surprised that Google searches didn't turn up any results, which makes
me wonder if it might just be something peculiar to my Mac.
David K. Woods, Ph.D.
Researcher, Transana Lead Developer
Wisconsin Center for Education Research
University of Wisconsin, Madison http://www.transana.org
well, I, for one never use exp;licte IDs for anything, so I wouldn't have noticed.
I suspect that the number of people that have tested 2.8.12 on a Mac, and calling event.GetId() is pretty small -- maybe one!
-Chris
···
On 7/29/11 8:07 AM, David Woods wrote:
Is anybody else having trouble with event.GetId() on OS X?
I was surprised that Google searches didn't turn up any results, which
makes
me wonder if it might just be something peculiar to my Mac.
--
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
> Is anybody else having trouble with event.GetId() on OS X?
>
> In wxPython 2.8.9.2, event.GetId() returned the ID of the
control that
> triggered the event on OS X, just like it does on Windows.
>
> In wxPython 2.8.12.0 and 2.8.12.1, event.GetId() always
returns 0 on
> OS X. It still works correctly on Windows in wxPython 2.8.12.0.
For all types of events and widgets or just some?
>
> I was surprised that Google searches didn't turn up any
results, which
> makes me wonder if it might just be something peculiar to my Mac.
Perhaps. Command event bindings that are bound to a parent with a
specified source or ID would not work if the ID was not set
in the event.
Do you have a simple sample?
It's quite preliminary, but I've attached a first sample.
On OS X using wxPython 2.8.12.1, mouse over and press the button. You will
see that event.GetId() works fine. Mouse over the text control, and you're
still good. But type in the text control, and you'll see that EVT_KEY_DOWN,
EVT_CHAR, and EVT_KEY_UP events get a value of 0 for the text control.
(I think the problem does occur for some EVT_MOTION instances in my program,
but it may take a bit more investigation to understand the exact
conditions.)
Chris Barker writes:
well, I, for one never use exp;licte IDs for anything, so I wouldn't
have noticed.
I need to share a common method across a number of controls. What would you
suggest instead of explicit IDs?
Is anybody else having trouble with event.GetId() on OS X?
In wxPython 2.8.9.2, event.GetId() returned the ID of the
control that
triggered the event on OS X, just like it does on Windows.
In wxPython 2.8.12.0 and 2.8.12.1, event.GetId() always
returns 0 on
OS X. It still works correctly on Windows in wxPython 2.8.12.0.
For all types of events and widgets or just some?
I was surprised that Google searches didn't turn up any
results, which
makes me wonder if it might just be something peculiar to my Mac.
Perhaps. Command event bindings that are bound to a parent with a
specified source or ID would not work if the ID was not set
in the event.
Do you have a simple sample?
It's quite preliminary, but I've attached a first sample.
On OS X using wxPython 2.8.12.1, mouse over and press the button. You will
see that event.GetId() works fine. Mouse over the text control, and you're
still good. But type in the text control, and you'll see that EVT_KEY_DOWN,
EVT_CHAR, and EVT_KEY_UP events get a value of 0 for the text control.
(I think the problem does occur for some EVT_MOTION instances in my program,
but it may take a bit more investigation to understand the exact
conditions.)
Ok, those are all non-command events, so the issue is less troublesome there. While IDs should always be set on all events, not setting them for non-command events will not break the event processing system since they do not propagate.
It looks like this issue has been fixed in 2.9 as I get ID values for all events in your sample. I'll take a quick look and see if there is an easy fix for 2.8.
Chris Barker writes:
well, I, for one never use exp;licte IDs for anything, so I wouldn't
have noticed.
I need to share a common method across a number of controls. What would you
suggest instead of explicit IDs?
event.GetEventObject, and if you need it event.GetEventObject().GetId() should always work, except perhaps for menu/toolbar events.
Exactly -- I like to work with objects, rather than with IDs. We've got all of Python's nifty name spaces, why not use them?
But I rarely use that either, rather, I have the bindings set up so that I don't need to query what object an event came from. IN fact, I usually design things so that the event handler could be called in multiple ways.
If I want numerous objects to call the same event handler, and there is a need to know something about where it came from, I tend to use the "lambda trick" to pass info into the event handler:
well, I, for one never use exp;licte IDs for anything, so I wouldn't
have noticed.
I need to share a common method across a number of controls. What
would you
suggest instead of explicit IDs?
event.GetEventObject,
--
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
I believe this is normally the right approach, but it falls short when
handling UpdateUI events for menubars and toolbars. I can't remember a
single example dealing with UpdateUI events without getting into event
IDs. If such an example exists, it is bound to be more complex than
the standard approach:
well, I, for one never use exp;licte IDs for anything, so I wouldn't
have noticed.
I need to share a common method across a number of controls. What
would you
suggest instead of explicit IDs?
event.GetEventObject,
Exactly -- I like to work with objects, rather than with IDs. We've got all
of Python's nifty name spaces, why not use them?
But I rarely use that either, rather, I have the bindings set up so that I
don't need to query what object an event came from. IN fact, I usually
design things so that the event handler could be called in multiple ways.
If I want numerous objects to call the same event handler, and there is a
need to know something about where it came from, I tend to use the "lambda
trick" to pass info into the event handler:
well, I, for one never use exp;licte IDs for anything, so I wouldn't
have noticed.
I need to share a common method across a number of controls. What
would you
suggest instead of explicit IDs?
event.GetEventObject,
Exactly -- I like to work with objects, rather than with IDs. We've got all
of Python's nifty name spaces, why not use them?
But I rarely use that either, rather, I have the bindings set up so that I
don't need to query what object an event came from. IN fact, I usually
design things so that the event handler could be called in multiple ways.
If I want numerous objects to call the same event handler, and there is a
need to know something about where it came from, I tend to use the "lambda
trick" to pass info into the event handler:
I believe this is normally the right approach, but it falls short when
handling UpdateUI events for menubars and toolbars. I can't remember a
single example dealing with UpdateUI events without getting into event
IDs. If such an example exists, it is bound to be more complex than
the standard approach: