Is there a table of common values for Chr and Chrb in Keydown(Key as string)?
Also, is there a language (French, or Russian) correspondence?
Can I always prepend the key value with &u as in Unicode?
I have the most dependable way is to go to a TextArea and key something in.
It doesn’t seem like it is relevant to the table in Keyboard or TextEncodings.
write a small app to collect them yourself (you will learn more that way)
// keydown
msgbox str(ascb(key))
keyboards can be locale sensitive, if this is what you mean
I don’t know what you are attempting to do, but based on recently asked questions… I have the feeling that you are attempting to write code to do things that are handled by the specific controls already
I am very sad with that, but the [quote]Chr(31)[/quote], which is what the keydown event reports in Key for down arrow key, does not equate from what I know with either of the possible values in Keyboard.
[quote]If Keyboard.AsyncKeyDown(125) then
//do something with the down arrow key…[/quote]
I have learned the hard way they are not the same.
I am asking only for a table that I can look up those values.
The Ascii value of 31 in our tables is not equal anywhere I have found to “Arrow Down”
not sure how many times I can suggest reading the supplied documentation
there are tables in the KEYBOARD section… (which Roger mentioned 10 minutes ago) although as specified different keyboards emit different values… .which is why I suggested the code snippet above.
Rely on your observations if you can’t find definitive documentation.
Thanks. I understand. I think apparently everyone goes through the same process which is definable and expected. That is sad.
The only table I can find relevant to keys is in Keyboard. As I recall, [quote]Keyboard.AsyncKeyDown[/quote] cannot be used in certain places. As I recall it should never be used in Keydown events.
Maybe I have that backwards. Is it backwards?
What do I prepend a code from the Keyboard table with so I don’t have to repeat what everyone else has done?
Alternatively, maybe I should make a feature request for keys for locale for contstants?
I’m not sure how to word this for FeedBack, since it would be user supplied.
method LinuxKeyCodeToKeySymbol(keycode as Integer, index as Integer) as Integer
method LinuxKeyNameToKeySymbol(keyname as string) as Integer
method LinuxKeySymbolToKeyCode(keysymbol as Integer) as Integer
method LinuxKeySymbolToKeyName(keysymbol as Integer) as string
method MacTextForKeyCode(keycode as Integer, KeyAction as Integer, ModifierState as Integer) as string
method WinScanCodeToVirtualKeyCode(ScanCode as Integer) as Integer
method WinVirtualKeyCodeToCharCode(VirtualKeyCode as Integer) as Integer
method WinVirtualKeyCodeToScanCode(VirtualKeyCode as Integer) as Integer
method WinVirtualKeyForASCII(Character as Integer, byref VirtualKeyCode as Integer, Byref ShiftKey as boolean, byref ControlKey as Boolean, byref AltKey as boolean) as boolean
you do not talk about extended keyboards vs standard (MacBook keyboards vs external keyboards). Did you forget (overlook) them ?
Worst: do you know you can change the keys from your keyboard using something in the Control Panel ?
(yes, I try to add confusion to confusion; set something not simple to very complicated).
More seriously:
if you want to use the hardware code for the characters in a keyboard, use KeyCode (eventually).
if you want to be able to deal with what is printed on the key caps, use Key.
You already get some good advices, but thinking ASCII ? I do not care about ASCII will not gives you any good.
What people are telling you that what value = what character.
BTW: avoid tables called Extended ASCII: they come from stupid who believes they are smart ! Go directly to Unicode. Nowadays, ASCII are the 128 first characters in the Unicode Table !
There is an “interesting” difference between platforms about keyboard handlers, key codes, and the correspondence between the generated character and the key code.
On Mac, the values of key codes are strictly related to their geographical position, which means for instance the upper left corner key of the typewriter always generate &h0C, no matter if I use the US keyboard layout (Q), or the French keyboard layout (A). Which means a table of values will be specific to a keyboard layout.
On Windows, the values of key codes are tied to the characters generated by the keyboard. For instance, the upper left corner when the US keyboard layout is used generates Q key code &h0C, but when using the French layout the same key generates A key code &h00.
So on Mac a character does not necessarily correspond to the same key code depending on the keyboard layout, while on Windows, the same key code does not necessarily correspond to the same geographical code, but always corresponds to the same character.
I just tested under Linux Mint, it is the same as Windows.
Thanks to all for the comments. It is now more clear than mud. I especially appreciate knowing that each Key versus KeyCode are interpreted differently for each locale.
This would be the ASCII table, and it doesn’t change. An “A” is always chr(65). It would be impossible to communicate otherwise. KeyCodes do vary by machine and keyboard layout. ASCII codes and Unicode codes do not.
When you’re in KeyDown, you really don’t care what physical key was pressed. You only care about the value of that key. Eg., it was an “A” as opposed to a “B”.
Actually, it is not interpreted differently per locale, but by keyboard layout, depending on the platform. Unless you have an imperious reason to use Keyboard.AsyncKeydown, you should leave it alone in favor of the key property in Keydown.
I went looking for what my Chr(8) meant and ran into this article.
So, I Thought to share this article on Wikipedia that is just one of the links from their KeycCode page.
Terminology is so important and so confusing. Scan Code
I also have no idea why I wanted to use the backspace key.
Arthur, that article is not relevant to Xojo at all, and besides, quite obsolete today. For instance, the key code for A is &h00, not anything like what is described on the Wikipedia page.
As I suggested before, I strongly advise to not get into key codes, unless you have no alternative.