Converting from keycode to "cooked" char

[Federico]

Hi everyone!

Given that wx.KeyEvents of the EVT_KEY_UP/EVT_KEY_DOWN type carry "virtual"
keyboard scancodes as keycode, and that EVT_CHAR events "cook" those
scancodes to "real" characters, is there a way to get the real character
from a EVT_KEY_* event?

[Tim Roberts]

Have you looked at the virtual key codes? For the keys that map directly to ASCII, the virtual key code IS the ASCII value. If you press the A key, the virtual key code will be 65, and chr(65) == 'A'. You have to look at GetModifiers to check the shift key to know whether it is 'A' or 'a', but the translation is trivial.

For the keys that don't have ASCII mappings (up, down, left, right, etc), there's really no way to do it.
--
Tim Roberts, ***@probo.com
Providenza & Boekelheide, Inc.

________________________________
From: wxpython-***@googlegroups.com [wxpython-***@googlegroups.com] On Behalf Of Federico [***@gmail.com]
Sent: Tuesday, September 23, 2014 6:46 AM
To: wxpython-***@googlegroups.com
Subject: [wxPython-users] Converting from keycode to "cooked" char

Hi everyone!

Given that wx.KeyEvents of the EVT_KEY_UP/EVT_KEY_DOWN type carry "virtual" keyboard scancodes as keycode, and that EVT_CHAR events "cook" those scancodes to "real" characters, is there a way to get the real character from a EVT_KEY_* event?

[Federico]

Post by Tim Roberts
Have you looked at the virtual key codes? For the keys that map
directly to ASCII, the virtual key code IS the ASCII value. If you press
the A key, the virtual key code will be 65, and chr(65) == 'A'. You have
to look at GetModifiers to check the shift key to know whether it is 'A' or
'a', but the translation is trivial.

Yes, but there are more tricky translations, such as SHIFT + a number key
on the top row :) For example on my keyboard SHIFT + 6 is &, but of course
other keyboard mappings could be different

[Werner]

Hi Federico,

Post by Tim Roberts
Have you looked at the virtual key codes? For the keys that map
directly to ASCII, the virtual key code IS the ASCII value. If
you press the A key, the virtual key code will be 65, and chr(65)
== 'A'. You have to look at GetModifiers to check the shift key
to know whether it is 'A' or 'a', but the translation is trivial.
Yes, but there are more tricky translations, such as SHIFT + a number
key on the top row :) For example on my keyboard SHIFT + 6 is &, but
of course other keyboard mappings could be different

Have a look at the wxPython demo 'KeyEvents' and look at the code and/or
wxpython.org/Phoenix/docs/html/KeyEvent.html

Werner

[Federico]

Post by Werner
Have a look at the wxPython demo 'KeyEvents' and look at the code and/or
wxpython.org/Phoenix/docs/html/KeyEvent.html

It looks like on my platform (GTK) GetRawKeyCode returns the "cooked"
keycode, excellent :) Many thanks!

[Robin Dunn]

Post by Werner
Have a look at the wxPython demo 'KeyEvents' and look at the code
and/or wxpython.org/Phoenix/docs/html/KeyEvent.html
<http://wxpython.org/Phoenix/docs/html/KeyEvent.html>
It looks like on my platform (GTK) GetRawKeyCode returns the "cooked"
keycode, excellent :) Many thanks!

Unless your application is only going to be running in English locales
with English speakers/writers with English keyboards then you probably
do not want to rely on that working.

The actual contents of the "raw" attributes of the event is undefined by
wx and is more or less a platform-specific value. And to make things
even more complex, with some keyboards or software-based input methods
there may actually be multiple key events before one "cooked" char event
is sent for the composed value. For English speakers, think about how
there are 2 key down events to get the char event for a capital 'A', one
for shift and one for 'a'. Now add 2 or more additional key down and up
events (with key codes that look like other ascii letters) before
finally getting one char event for some unicode glyph.

If you really need the cooked char the best thing to do is to wait for
the char event.

[Nathan McCorkle]

Post by Federico
Hi everyone!
Given that wx.KeyEvents of the EVT_KEY_UP/EVT_KEY_DOWN type carry
"virtual" keyboard scancodes as keycode, and that EVT_CHAR events "cook"
those scancodes to "real" characters, is there a way to get the real
character from a EVT_KEY_* event?

I thought I had to do this 'cooking' manually, and did it just by ASCII
mappings. I also handled things like backspace and delete. I was really
just trying to distinguish between Keyboard-driven input and
programmatically-generated input... later I found that I could have avoided
the whole 'cooking' step had I simply used ChangeValue instead of SetValue
for the programmatic changes.

While I did change all the programmatic SetValue stuff to ChangeValue, I
haven't updated my code yet, and as a result you can see an example in
ProcessKeyboard in the file attached to this post:
https://groups.google.com/d/msg/wxpython-users/UpzLt8cDoqA/njYzDhzA-y8J