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?
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, timr@probo.com
Providenza & Boekelheide, Inc.
From: wxpython-users@googlegroups.com [wxpython-users@googlegroups.com] On Behalf Of Federico [jorilx@gmail.com]
Sent: Tuesday, September 23, 2014 6:46 AM
To: wxpython-users@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?
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
On Tuesday, September 23, 2014 6:46:23 AM UTC-7, Federico wrote:
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?
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
On Tuesday, September 23, 2014 11:59:31 PM UTC+2, Tim Roberts wrote:
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.
Have a look at the wxPython demo ‘KeyEvents’ and look at the code
and/or wxpython.org/Phoenix/docs/html/KeyEvent.html
Werner
Hi Federico,
On 9/24/2014 11:30, Federico wrote:
On Tuesday, September 23, 2014 11:59:31 PM UTC+2,Tim Roberts wrote:
Have you looked at the virtual key codes? For thekeys 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 + anumber key on the top row
- 6 is &, but of course other keyboard mappings could be
different
It looks like on my platform (GTK) GetRawKeyCode returns the “cooked” keycode, excellent Many thanks!
On Wednesday, September 24, 2014 11:38:39 AM UTC+2, werner wrote:
Have a look at the wxPython demo 'KeyEvents' and look at the code
Federico wrote:
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
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.
On Wednesday, September 24, 2014 11:38:39 AM UTC+2, werner wrote:
--
Robin Dunn
Software Craftsman