In this new world of multiple text encodings where we support a myriad of alphabets, how do I tell if the character being passed to me from a keyDown event is a printable character or something else?
Im just doing a type to select matches sort of thing in a listbox. I add the key passed to the keyDown event to a search buffer or replace the search buffer contents with it depending on how long its been since you last pressed a key. Then I walk the list and highlight the first name that starts with what youre typing. Pretty standard interface stuff for a window that has a long list but doesnt implement a search field.
Back in the old days of ASCII I could check to see if the asc() value of the key passed to the event was greater than 32 or less than 127 to make sure I wasnt trying to add a tab or a del or return keypress to my search buffer. Im not sure thats a valid technique anymore?
Is there a proper way to tell if a character should be treated as a printable character like an actual letter that might be part of a word, as opposed to some other glyph or control character now with multi-character sets and many text encoding systems?
values less than 0x20 (32) are still the standard control characters
but anything greater than 0x7F will return varying “printable” results" based on font and/or encoding
[quote=240233:@James Sentman]Back in the old days of ASCII I could check to see if the asc() value of the key passed to the event was greater than 32 or less than 127 to make sure I wasnt trying to add a tab or a del or return keypress to my search buffer. Im not sure thats a valid technique anymore?
Is there a proper way to tell if a character should be treated as a printable character like an actual letter that might be part of a word, as opposed to some other glyph or control character now with multi-character sets and many text encoding systems?[/quote]
In the Unicode standard, less than 127 is still “non printable”. Anything else is a glyph.
There is, however, the notion of “combining diacritics”, which are not consider characters per themselves, as they are supposed to be used in combination with letters. But they are still “printable”.
Another matter is the undefined characters in a font. They can be spotted by drawing them into a picture and comparing with the result of a blank space (convert the picture to string for easy comparison).
I don’t think you need to worry too much. By default a textfield doesn’t accept tabs or returns, delete is auto handled for you. It’s almost impossible for a user (on OS X anyway) to manually type a control char.
Also I wouldn’t do it in the keydown event, have you seen people type Chinese, they have to press 3 keys to get one symbol.
As long as you’re using the contents of the textfield instead of building your own string by appending KeyDown characters, you really don’t need to worry about any of that. If you are building your own string, then you need to deal with control characters, Delete, and Backspace. But it’s best to let the textfield to the heavy lifting for you.