You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MSKLC will use a bitmap for determining if a key is affected by CAPS LOCK. For shift, this will be a value 1, which properly parsed into a boolean true. A more complex layout like EurKEY has this flag set for the AltGr level as well, causing the value to be 4 or 5.
The parser seems to fail on any other value then 0 or 1.
The text was updated successfully, but these errors were encountered:
Quite. That's the Caps State entry, the second entry for each key not counting the scan code itself, iirc. If the AltGr+Shift glyph is a shifted version of the AltGr one, its value is OR'ed by 4 as Vdelau said.
DreymaR is right, the value is OR'ed by 4 if AltGr is affected by Caps Lock. However, KLFC currently doesn't support different behavior for different levels. I fixed the parsing issue by ignoring other levels.
MSKLC will use a bitmap for determining if a key is affected by CAPS LOCK. For shift, this will be a value 1, which properly parsed into a boolean true. A more complex layout like EurKEY has this flag set for the AltGr level as well, causing the value to be 4 or 5.
The parser seems to fail on any other value then 0 or 1.
The text was updated successfully, but these errors were encountered: