Hi, George,

Yes, you're absolutely right. The parameter received is actually something called a "Windows key code", and the significant ones are defined in some constants I found after digging around a little more in the documentation. Well, duh!

OK, now that I know what they are, I can use them as is.

Thanks for clearing up my misunderstanding.

I did find that Key Scan Code table. Its the same table in my very old (Copyright 1984)Assembly Language reference, which may be where it came from.

George, best wishes for the Holiday and a happy New Year.

Thanks again,

JME

>Are you sure that it's using the scan codes? These can be dependent on the manufacturer and/or locale. Using the scan codes rather than the virual key codes (which Windows sends to applications after translating from the scan code) would be pretty limited. The following is from MS KB article Q104316:
>
>"Keyboard input is acquired by the keyboard driver, which in turn produces a scan code. This scan code is passed on to the locale-specific Win32 subsystem keyboard driver. This locale-specific driver then converts the scan code to a virtual key and a Unicode character. The Win32 subsystem then passes on this information to the application.
>
>All messages in the Win32 application programming interface (API) that present textual information to a window procedure depend upon how the window registered its class. For example, if RegisterClassW() was called, then Unicode is presented; if RegisterClassA() was called, then ANSI is presented. The conversion of the text is handled by the Window Manager. This allows an ANSI application to send textual information to a Unicode application."
>
>It just seems dubious to me that a control would be by-passing the sub-system to get this information.
>
>I did a search on "scan codes" in the MSDN library. There is a chart there that might be useful. The closest thing to an API call would be VkKeyScan, which takes a character and translates it to the virutal key code.