Hi Guillaume,
I'll try to explain those one-by-one, although in some cases this is behavior that goes back almost 20 years, and I can only guess as to the original reasons:
I press [A]:
0x00000061 - 'a' - Remains 0x00000000
Shouldn't that be 'A' ??
Only modified keys convert the character code to uppercase. A simple keypress on a letter key leaves the letter unmodified. If you only press the letter key, without the <Shift> modifier, you should expect to receive the lower-case letter code, since that is what you pressed. If you press <Shift-A> that is still considered an unmodified key (more on that below, in the [Shift-A] discussion). But in that case, the 'a' is converted to uppercase since that is the effect of the <Shift> key.
I press [Ctrl-A]:
0x00140041 - Ctrl 'A' - Remains 0x00100000
Why is bit 20 activated ? It's not referenced as far as I can tell.?
This extra bit is only present in Linux, from what I can tell. I did some debugging to find out why the bit was set, and my best guess is that this is a holdover from the CVI for Sparc days (where a lot of the Linux-specific code migrated from) in order to account for additional modifier keys in the Sparc keyboard. Whereas modern PC keyboards have only the <Ctrl> key, I believe that Sparc keyboards in the past had an additional modifier key (<Opt> key?). Therefore, in keyboards that had only the <Ctrl> key, the policy back then was that the <Ctrl> key mapped to both keys on the Sparc, and two flags were set accordingly. In Unix, those flags have different bit values, and that is why there is an extra bit in Linux. I can't really justify this behavior today, other than that it needs to be preserved for backwards compatibility. I think you should simply ignore that bit when you check for the presence of the various modifiers.
I press [Shift-A]:
0x00000041 - 'A' - Remains 0x00000000
Why is bit 16 NOT activated ??
When you press <Shift-a>, your keyboard translates that into simply 'A'. That is the policy whenever you have a simple <Shift> modifier applied to any of the alphanumeric characters. Note that this also applies to number keys ('1', '2', ...) since these keys have a different character that is sent whenever the <Shift> key is pressed. For example, in the English-language keyboard, the key with the number '2' has the '@' symbol above it. Therefore, when I press <Shift-2>, that event is translated by the keyboard driver into <@> and CVI then removes the <Shift> modifier. By contrast, when you press <Shift-F1>, the <Shift> modifier remains, since <F1> is never converted into another character.
The bottom line is that a <Shift>, as the lone modifier, is a special case when applied to a single alphanumeric character. It doesn't really count as a modifier. Instead, it simply determines which ASCII character you really get ('a' or 'A', '2' or '@', etc...)
I press [Alt-A]:
0x00020061 - Alt 'a' - Remains 0x00000000
Shouldn't that be 'A' ?
No, it should not. For the same reason that pressing [A] results in 'a', <Alt-A> also results in <Alt> + 'a'.
I press [Shift-Alt-A]:
0x00030041 - Shift Alt 'A' - Remains 0x00000000
So now we get the shift bit in addition to the uppercase ? That's just not
consistent.
This is because <Shift-Alt-a> is a modified keypress and in those cases, the <Shift> bit is not removed, and the character code is promoted to uppercase.
I press [Shift-Ctrl-A]:
0x00150041 - Shift Ctrl 'A' - Remains 0x00100000
Bit 20 again
This is for the same reason that <Ctrl-A> has bit 20 set.
I press [Ctrl-Alt-A]:
No event...
The <Ctrl-Alt> modifier combination is filtered out, in Windows. I believe it is sent in Linux. Unfortunately I can't tell you why this is, as this is also very old behavior and, even though it is intentional, I don't know the rationale for it. I suspect that this is why you cannot use <Ctrl-Alt> as a hot key combination for a control -- only <Ctrl>, <Shift>, and <Ctrl-Shift>.
I press [Shift-Ctrl-Alt-A]:
0x00170041 - Shift Alt Ctrl 'A' - Remains 0x00100000
Bit 20 again
This is for the same reason that <Ctrl-A> has bit 20 set.
Luis
