On Tue, Mar 02, 2010 at 04:21:01PM -0800, B W wrote: > On Tue, Mar 2, 2010 at 2:54 PM, Greg Ewing <greg.ew...@canterbury.ac.nz>wrote: > > > B W wrote: > > > >> Assuming these are UTF8 characters, the encoding is backwards compatible > >> with ASCII. Therefore, you should be able to use the ASCII chart to > >> classify > >> non-printable character codes (0-31 and 127). > >> > > > > There's no standard ASCII code for arrow keys, however, and > > I've seen at least some systems translate them into non-ASCII > > unicode characters. > > > True. There is no ASCII code for a cursor key. Those keys send multi-byte > raw ASCII sequences, unlike other keys that send a single byte. I notice > Pygame (or SDL?) seems to cook them into a semblance of ASCII. However, for > the Enter key on my Winders event.key reports 13 as expected, while UP arrow > reports 273 (blank string?) which is higher than 255.
That's my exact problem. I guess I'll have to do as suggested and go through the list of K_* and manually find all of the ones I want to exclude. > I haven't had a need to delve into event.unicode (<type 'unicode'>). Does it > represent the raw keys? In my case, for UP arrow they are > (K_ESCAPE,K_O,K_A). It returns the actual unicode character that the user expects a certain key or key combination to result in. E.g. on a Chinese keyboard it will return a chinese character when the user hits the key for that character. Chris. ------------------- http://mccormick.cx
