![]() Caps Lock is an important key for accessibility and Narrator. We should make sure this doesn't break Narrator support.This was the same thing that occurred in the original PT Run and ColorPicker hook implementations as modifiers were recorded in bool variables rather than using GetAsyncKeyState. ![]() We can guarantee it would work correctly only if elevated. Since we aren't using GetAsyncKeyState quirks can occur if a user switches between elevated and unelevated windows.Wherever we reset back to the pressed modifiers, we can still sendInput CapsLock, but it should get read by the `UpdateCapsLockBoolState` method. Remap to Ctrl+V (same as existing logic). UpdateCapsLockBoolState(currentKeyEvent->keyUpOrDown) If (CapsLockModifierBehavior & current key=CapsLock) Suppress all caps lock events and update state Assume a bool variable is present in KBM state or some class like that which stores the state of Caps Lock. This is equivalent to storing our own keyboard state variable rather than using GetAsyncKeyState. Instead we have to workaround this by having our own bool variable which updates CapsLock state on receiving Caps key events. ![]() We can't use GetAsyncKeyState for checking if Caps Lock is pressed, since we have to suppress Caps Lock events to prevent the oridinary behavior. Implementation in the backend (Pseudo-C++ code): We have to fix it to be one of the two behaviors, either modifier or action key, can't have both.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |