From: Michael \(michka\) Kaplan (michka@trigeminal.com)
Date: Tue Dec 30 2003 - 14:27:21 EST
From: "Adam Twardoch" <list.adam@twardoch.com>
> 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
This archive was generated by hypermail 2.1.5 : Tue Dec 30 2003 - 15:06:18 EST