wx.TextCtrl on GTK produces bad unicode character in EVT_CHAR handler

A problem that only occurs on GTK (Windows seems fine): running the
attached sample produces a shifted GetUnicodeKey when compared to the
GetKeyCode value when an EVT_CHAR event handler is attached to a
TextCtrl. Attaching the handler to a StyledTextCtrl or a plain
wx.Window doesn't show this problem.

The demo shows that pressing an unshifted "a" on the keyboard should
produce the unicode value 97, but in the output for TextCtrl produces
the shifted 65, i.e. "A".

Sample output:

TextCtrl: ascii: (97, 'a') unicode: (65, u'A')
STC: ascii: (97, 'a') unicode: (97, u'a')
Wx.Window: ascii: (97, 'a') unicode: (97, u'a')

I'm stumped. I tried it on two different linux machines, using
2.8.9.1 and 2.8.9.2 with the same results

Thanks,

Rob

unichar-test.py (3.83 KB)

Following up to my own post, some additional google-fu turned up a
2006 mailing list post:

http://lists.wxwidgets.org/pipermail/wxpython-users/2006-November/057266.html

which implied that it was a problem with the native widget's
interaction with the toolkit, and there wasn't a direct solution.

Rob

ยทยทยท

On Wed, May 6, 2009 at 1:49 PM, Rob McMullen <rob.mcmullen@gmail.com> wrote:

TextCtrl: ascii: (97, 'a') unicode: (65, u'A')
STC: ascii: (97, 'a') unicode: (97, u'a')
Wx.Window: ascii: (97, 'a') unicode: (97, u'a')