Re: evt.GetUnicodeKey returns int instead of string

Werner <[email protected]>
Newsgroups gmane.comp.python.wxpython.devel
Message-ID <[email protected]>
On 4/15/2015 18:55, Robin Dunn wrote:
> Werner wrote:
>> Hi Robin,
>>
>> I am looking into this again as I run into another issue with it in my
>> software.
>>
>> I wonder if the documentation is correct, and classic is not doing the
>> right thing, but Phoenix does (even so my first post said it did act as
>> classic did:-[ ).
>>
>> evt.GetKeyCode()
>> 111
>> evt.GetUnicodeKey()
>> 111
>> wx.VERSION_STRING
>> '2.9.5.0'
>>
>> evt.GetKeyCode()
>> 111
>> evt.GetUnicodeKey()
>> u'o'
>> wx.VERSION_STRING
>> '3.0.3.dev1784+18750f4'
>>
>
>
> I think that the correct thing to do for Python would be to have both 
> methods return integers.  That seems more consistent to me, since they 
> are basically doing the same thing, returning a code that either 
> represents the physical key on the keyboard, or possibly the cooked 
> value or a value generated by the IME, depending on the type of event. 
> Although it may just be my C roots showing but to me a single 
> "character" is an integer value in a specific range, which is 
> different than a string of length 1 (because it will actually be a 
> collection of 2 characters including the termination byte.)
>
> Python has chr() (and unichr() in 2.7) to convert the numeric values 
> to a string or unicode object if needed.
>
> Thoughts?
I think it is nice the way Phoenix handles it.

wx.VERSION_STRING
'3.0.3.dev1784+18750f4'
evt.KeyCode
59
evt.GetUnicodeKey()
';'

What do we get if GetUnicodeKey is also returning 59 in this case?

If we need to use chr/unichr to get the typed character then we would 
also need to check for Py version - not so nice:-) .

My vote would be that GetUnicodeKey works as in Phoenix (until the 
14th;-) ), and that classic should be adjusted.

Werner

-- 
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.