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, ti...@probo.com
Providenza & Boekelheide, Inc.

 

---

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

[Nathan McCorkle]

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?

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

[Federico]

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.

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,

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

Werner

[Federico]

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 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]

Federico wrote:
>
> 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
> 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.

--
Robin Dunn
Software Craftsman
http://wxPython.org