Explanation needed on TryToTranslateChar...

[Johannes Olofsson]

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

[art yerkes]

On Thu, 10 Mar 2005 18:29:29 GMT 
"Johannes Olofsson" <johannes_olofsson(a)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.
-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman