Trying to catch event char

Hi,

I have a frame with a notebook and two tabs within the notebook.

I use: self.Bind(wx.EVT_CHAR, self.Event_Key_Down)

To catch the keys and process them.

This works fine under Linux but I do not get the event under Windows.

Any help greatly appreciated.

Regards,

Philippe

···

--
_________________________
Philippe C. Martin
www.snakecard.com
_________________________

Philippe C. Martin wrote:

I have a frame with a notebook and two tabs within the notebook.

I use: self.Bind(wx.EVT_CHAR, self.Event_Key_Down)

What is 'self' here? The notebook, or one of the widgets making up a page, or a widget within the page, or the frame itself?

To catch the keys and process them.

This works fine under Linux but I do not get the event under Windows.

Any help greatly appreciated.

The key events are not command events so they don't propagate up the containership hierarchy. The only object that will see them is the one that currently has the focus. On Windows, you can click on even a non-interactive widget and all of a sudden it has the keyboard focus, while on Linux and Mac this is not true. Additionally, the object that has the focus initially will vary among all three platforms. You can explicitly set focus using either of:

SetFocus()
SetFocusIgnoringChildren()

That second one would be useful to set focus to a frame, notebook, or panel without the focus going to the first child in those containers. So, if you want to respond to EVT_CHAR in the Frame, the frame needs to have focus for that to work. Not very useful, as the focus will change depending on user actions.

Therefore, depending on your needs you may need to bind EVT_CHAR to every single widget that could possibly get the focus. Bind 'em all to the same callback, and handle the KeyChar's centrally.

The other idea I have is to bind EVT_CHAR to your wx.App instance. Even though non-command events don't propagate, the application object has a final chance at them if they weren't handled yet already. Note that I've tried this and it basically worked, but there are plenty of special keys that don't make it this far because they've already been handled by wxPython or by the native UI toolkit.

Note that I believe I'm correct in everything I say above, and that I'm not missing any other options, but I've been wrong before and would welcome corrections.

I'd love to see a feature where a given object could be set to receive all key events *first*, before the event goes to the object with the focus. In my work, this would usually be the containing form, but it could also certainly be the app.

···

--
Paul McNett
http://paulmcnett.com
http://dabodev.com

Thanks,

self is the notebook.

I tried to catch it in the frame but with no success (maybe a focus matter)

I had to bind the event to the control (and set the focus as you mentionned)
to have an equivalent, though not as nice, behavior under both OSs:
self.GetTextctrlAmount().Bind(wx.EVT_CHAR, self.Event_Key_Down)

Regards,

Philippe

···

On Thursday 20 April 2006 11:21 am, Paul McNett wrote:

Philippe C. Martin wrote:
> I have a frame with a notebook and two tabs within the notebook.
>
> I use: self.Bind(wx.EVT_CHAR, self.Event_Key_Down)

What is 'self' here? The notebook, or one of the widgets making up a
page, or a widget within the page, or the frame itself?

> To catch the keys and process them.
>
> This works fine under Linux but I do not get the event under Windows.
>
> Any help greatly appreciated.

The key events are not command events so they don't propagate up the
containership hierarchy. The only object that will see them is the one
that currently has the focus. On Windows, you can click on even a
non-interactive widget and all of a sudden it has the keyboard focus,
while on Linux and Mac this is not true. Additionally, the object that
has the focus initially will vary among all three platforms. You can
explicitly set focus using either of:

SetFocus()
SetFocusIgnoringChildren()

That second one would be useful to set focus to a frame, notebook, or
panel without the focus going to the first child in those containers.
So, if you want to respond to EVT_CHAR in the Frame, the frame needs to
have focus for that to work. Not very useful, as the focus will change
depending on user actions.

Therefore, depending on your needs you may need to bind EVT_CHAR to
every single widget that could possibly get the focus. Bind 'em all to
the same callback, and handle the KeyChar's centrally.

The other idea I have is to bind EVT_CHAR to your wx.App instance. Even
though non-command events don't propagate, the application object has a
final chance at them if they weren't handled yet already. Note that I've
tried this and it basically worked, but there are plenty of special keys
that don't make it this far because they've already been handled by
wxPython or by the native UI toolkit.

Note that I believe I'm correct in everything I say above, and that I'm
not missing any other options, but I've been wrong before and would
welcome corrections.

I'd love to see a feature where a given object could be set to receive
all key events *first*, before the event goes to the object with the
focus. In my work, this would usually be the containing form, but it
could also certainly be the app.

--
_________________________
Philippe C. Martin
www.snakecard.com
_________________________