Mirrors | Updates | Feedback | Changes | Wishlist | Team
When using a keyboard layout that uses dead keys (such as German, or US International) on Win2K or XP, entering a non-composing sequence (such as a pair of circumflexes), such that the second keypress resulted in two characters, gave the wrong result (the second character was wrong).
Changing the storage behind the
lpChar argument of
BYTE, and using a pointer
cast, makes it work properly on 2K/XP. (Done as of 2004-03-25.) The
documentation isn't clear what type the storage behind the pointer
should be, but Googling indicates that this usage is not uncommon.
However, this breaks the same situation in (French and German) Win98SE,
which was working OK before with the
WORD array. (But
fixes it for French Win2K.) The storage of the array is conditionalised
on Windows version as of 2004-03-27. *crosses fingers*
This area is rich in history. For example:
ToAsciiExto fix a problem a Lithuanian user was having with top bits being stripped.
ToAsciiExdidn't work on Korean Win98 (but was OK on WinMe and 2000), whereas
ToAsciiwas fine. We didn't do anything about this because it seemed just too horrible.
keysarray before passing it to
ToAsciiExmakes a difference, which could be consistent with a confusion like that described above.
I've got a horrible suspicion that it's not as simple as a Win9x/NT split; this function appears to be an interface to the keyboard driver, and MS's specification of that interface on their website looks unclear to me, so I suspect that whether it's an array of bytes or words is dependent on the keyboard driver in question.
We could in principle try to detect it by initialising the array with unlikely values and seeing what changes. Bleurgh.
This may be the root of some other keyboard problems people have been having, too, if we're lucky. If our hacking in this area makes a difference to you (positive or negative), please let us know.
Audit trail for this semi-bug.