Michael, Peter, and others: Thank you for the responses.
I agree with Michael that the simplistic approach I have envisioned would be rather incomplete -- I'm willing to accept that limitation. I am aware of many issues involving IMEs, "chaining" dead keys etc. I would be willing to leave them out of the scope, i.e. I'd be willing to accept as much as it gets within a somewhat "flat" table. I have since then read some descriptions of Windows API functions. For example, I found out that the Windows user32.dll function VkKeyScanEx translates a character to the corresponding virtual-key code and shift state. This makes me conclude that Windows developers already had this kind of "back-lookups" in mind, and were willing to accept the limitations. I guess with some API calls, I should be able to put together such table, or even a mechanism to gather the information dynamically. I will be writing in Python for Windows, so it's a bit awkward to gather all that information. But maybe I'll try to prototype in C++ (a pity I'm so bad at C++ programming). (Michael,) from my understanding, when I have a Unicode character, I should be able to translate it to a virtual key code via VkKeyScanEx, then the virtual key code to a scan code using MapVirtualKey, and finally translate the result to a human-readable name using GetKeyNameText. Is that a correct approach? Does anybody happen to have a ready-to-use function (C++, VB, Python)? :D (Peter,) I am aware that there is a XML-to-driver mechanism that can be used. But is there a way the other way around? I.e. a way from the existing system kyboard mappings to a human-readable form? Thank you, Adam
