Hi! Could somebody help me out and explain how the TryToTranslateChar function in \reactos\subsys\win32k\ntuser\keyboard.c is supposed to work...
First there is the following definition: shift = keyLayout->pCharModifiers->ModNumber[ModBits];
which is later used in: CapsMod = shift | ((CapsState & CAPITAL_BIT) ? vkPtr->Attributes : 0);
which is used for the translation: *pwcTranslatedChar = vkPtr->wch[CapsMod];
Doesn't shift contain the index for the VK_TO_CHARSx table in the keyboard layout data structure?
Why is it then |:ed with vkPtr->Attributes , which I suppose corresponds to the CAPS/NOCAPS constants in the keyboard layout files ?
Shouldn't it be something like: shift = keyLayout->pCharModifiers->ModNumber[ModBits ^ ((CapsState & CAPITAL_BIT) ? vkPtr->Attributes : 0];
Regards Johannes Olofsson
10 Gigabyte Mailbox - http://mail.spray.se
On Thu, 10 Mar 2005 18:29:29 GMT "Johannes Olofsson" johannes_olofsson@spray.se wrote:
Hi! Could somebody help me out and explain how the TryToTranslateChar function in \reactos\subsys\win32k\ntuser\keyboard.c is supposed to work...
First there is the following definition: shift = keyLayout->pCharModifiers->ModNumber[ModBits];
ModNumber[ModBits] looks up to a column number in the vkToWchar tables, as I remember.
which is later used in: CapsMod = shift | ((CapsState & CAPITAL_BIT) ? vkPtr->Attributes : 0);
Here, we're putting vkPtr->Attributes (either CAPS or NOCAPS) into the shift number if it isn't there already. Now that you point it out, this is wrong because shift does not negate capslock. I think it is close in other respects though.
which is used for the translation: *pwcTranslatedChar = vkPtr->wch[CapsMod];
Doesn't shift contain the index for the VK_TO_CHARSx table in the keyboard layout data structure?
It contains the index of a column to look inside. That's why we scan the tables to determine which table the vk lies in. If vk is in a narrower table, we must do something. I truncate CapsMod but this may not be totally correct. I believe we need to tolerate extra modifiers so that Alt modifer can be used to generate syskey messages. This may be handled as a special case in real windows however.
Why is it then |:ed with vkPtr->Attributes , which I suppose corresponds to the CAPS/NOCAPS constants in the keyboard layout files ?
Shouldn't it be something like: shift = keyLayout->pCharModifiers->ModNumber[ModBits ^ ((CapsState & CAPITAL_BIT) ? vkPtr->Attributes : 0];
You are likely right that Attributes should affect the set modifier bits rather than column number. They happen to correspond in most instances (shift-a adds both 1 to modifier bits and 1 to column number), which is probably why this hasn't come up before.
-
art yerkes -
Johannes Olofsson