BuildKeyCode Method

[ChrisGreaves]

BuildKeyCode Method offers two identical tables; I shall ignore the second.
The first table offers a list of acceptable key codes for the assignation of various combinations of Sjhift/Ctrl/Alt and other keys to macros.
I have used these successfully in the past, and will continue to do so, but am struck by the apparent mis-match between an individual code and its ASCII equivalent, and can't fathom why Microsoft would make the distinction.
wdkeyc and asc("C") return the same value; makes sense to me⁽¹⁾.
But wdKeyBackSlash returns 220 whereas asc("\") returns 92; makes no sense at all to me.
I am happy with wdKeyShift = 256, wdKeyControl = 512, wdKeyAlt = 1024 and the accumulative nature of BuildKeyCode.

What ought to be a fairly simple matter of translating a keyboard character via BuildKeyCode - easy to do with the alphabetics and numerics - simply use their ascii codes - becomes a bit of a nightmare with the punctuation characters, requiring a careful mapping to non-obvious numeric values.

⁽¹⁾ Well, OK, It has an extra 128 thrown in.
When I look closely, the punctuation characters all seem offset by 128 - a pleasant number - but I still can't dream up a good reason for so doing.

[HansV]

Keycodes are NOT ASCII codes, even though they happen to coincide for letters and digits. Perhaps it would have been better if Microsoft had chosen completely random codes, then you wouldn't have wondered...

[ChrisGreaves]

Perhaps it would have been better if Microsoft had chosen completely random codes, then you wouldn't have wondered...

Absolutely.
I'd bet that they started off as ASCII codes, then someone got leery of the function keys or the Ctrl/Shift/Alt keys, and so a decision was made to rout the characters through the BuildKeyCode interface so that Microsoft retained absolute control of the generation.
I wrote a crude translator for ASCII codes which seems to lie in complete agreement with BuildKeyCode.

Now back to work ....