[wxPython-users] Keycode vs UnicodeKey in wx.EVT_CHAR

[Josiah Carlson]

Johannes Vetter <johannes.vetter at bytewise.at> wrote:
> Am Samstag, den 04.11.2006, 09:50 -0800 schrieb Josiah Carlson:
> > Johannes Vetter <johannes.vetter at bytewise.at> wrote:
> > [snip]
> > > I've tried that sample and the KeySink instance (which derives from
> > > wx.Window) handles the EVT_KEY* events as expected.  But this
> > doesn't
> > > help me much, since I have to catch the EVT_CHAR for wx.TextCtrl
> > which
> > > does not handle it right.  Is there a way to circumvent this
> > > shortcomming for wx.TextCtrl ?
> > 
> > What you can do is to check the key code and the state of the shift
> > key. 
> > Based on the value of the shift key and what you expect, you can
> > adjust
> > the values you process. 
> 
> Actually the problem is not only uppercase vs lowercase.  The real
> problem is, that I cannot rely on the Unicode-Value and since the
> application will be used in environments using other languages/charsets
> than latin-1 the only way to go is unicode (it's used for chinese as
> well as cyrillic and much more).  So i think to do a manual lower()
> depending on event.ShiftDown() might not be enough.  My point of
> interest is still: why does it work for a wx.Window but not for a
> wx.TextCtrl, and (more importaint than that) is there a way to
> circumvent this shortcoming.

Why doesn't it work and is there a way?  I don't know.  I have found
that the following seems to work fairly well for normalization, at least
with regards to characters that I have been able to type in.  Your
mileage may vary.

    ukey = evt.GetUnicodeKey()
    if ukey < 128:
        keycode = evt.GetKeyCode()
    else:
        keycode = ukey
    if keycode < 256:
        cha = chr(keycode)
    else:
        cha = unichr(keycode)


 - Josiah