Table of values for Chr and Chrb for Key

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

Thanks Dave. Good to know. it is that individual for controls and locale as in languages.

Google ASCII table

The key code and the ASCII value are not the same. Look up KeyCode in Xojo help. Those are the values which begin with the unicode symbol (&u)

Argh. There is no Keycode entry in

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]

This is because you are confusing KEYCODE and KEYVALUE

125 is the KEYCODE for down arrow
31 is the ASCII key VALUE for the same

NOTE : KEYCODE is subject to change across various keyboard localizations, KEYVALUE much less so…

Please take some time to read the documentation that Xojo was kind enough to provide

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.

Well, if you use MBS Plugins, you can look into RemoteControlMBS module.

There are methods for Mac, Windows and Linux:

  • 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 !

Good luck.

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.

Good luck…

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.

You will find here a project + that display an ASCII Table.

Totally useless (in Google, type ASCII Table to get some…), but asked here and answered here (do yours).

Read a more recent entry for details.

Exported table from the project.

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.