From: "Adam Twardoch" <[EMAIL PROTECTED]> > 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.
Fair enough. Note that even normal dead keys will not be very useful in a flat table -- you will have to have a way to map two keystrokes to one UTF-16 code point, > 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. Well, I never said it was impossible to get the information (in fact MSKLC uses the keyboard APIs in user32 extensively to do its work to "load from an existing layout"). Just that it is nowhere near a flat table, by any means. > (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 This will not work well for several reasons: ** GetKeyNameText only works witth the current layout and there is no GetKeyNameTextEx. If you ask me, GetKeyNameText is a little silly API, which relies on the strings added in each individual DLL (some localized, some not). The "localization" not very consistent between keyboards, either. You would essentially be reading information from specific keyboards and then trying to describe them as one particular one (whichever one you happened to be using as your keyboard in the current thread). ** Another problem is in using VkKeyScanEx here. Do you plan to throw all of Unicode at every single keyboard? ** Yet another problem with this approach is that none of the dead keys will show up with it; it will only find single characters that came from single keystrokes. ** And yet another problem is that no ligatures will work (same problem as above). Could we take a step back for a moment? If you could clearly explain what you planned to do with the files it might be easier to suggest a course of action. All I can do with the current plans is poke holes in the problems based on my own experience with "keyboard interrogation". You may also want to mark the thread "OT" since its not really much to do with Unicode.... MichKa [MS] NLS Collation/Locale/Keyboard Development Globalization Infrastructure and Font Technologies
