write a small app to collect them yourself (you will learn more that way)
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]
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.
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.
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.