kaleidoscope::hid::isModifierKeyActive()?

I feel like I’m not understanding this function—either it doesn’t do what I think it does, or it’s broken, or I’m broken … something.

Anyway, my understanding is that the isModifierKeyActive(Key_LeftShift) should return true if the left shift is being held. If that’s the case, then the following code should mean that holding left shift and typing any key will result in no output from the keyboard:

if(kaleidoscope::hid::isModifierKeyActive(Key_LeftShift)) {
  return EventHandlerResult::EVENT_CONSUMED;
}

(Why anyone would want to do this is beyond me, but bear with me, here.)

Adding that to the top of my EventHandlerResult Plugin::onKeyswitchEvent() method doesn’t do anything, though. LShift+T still happily prints T. And yes, the plugin is properly loaded.

I’m clearly not understanding something, so what is it? Is it possible I’m somehow pulling from the x86 source instead of the avr source? (I don’t see how that can be, but I’m really struggling.)

My information may be slightly out-of-date, but I believe that what you want is kaleidoscope::hid::wasModifierKeyActive. I think it’s something like isModifierKeyActive just checks if the modifier key was pressed in the current key reporting cycle, where wasModifierKeyActive checks if it’s currently held down. Kind of confusing names, for sure…

1 Like

As @james.nvc suggested, you can try using .wasModifierKeyActive(). The difference is that .isModifierKeyActive() checks if the key is active in the current report, which at the time of onKeyswitchEvent, is still building up. So if the firmware didn’t process a shift key yet, it will not return the expected result. It’s more useful in hooks that run after onKeyswitchEvent. On the other hand .wasModifierKeyActive() checks if the key was active in the previous report - it’s usually safe to work based on that.

And yes, the names aren’t exactly stellar… :frowning:

1 Like

Thanks to both of you; wasModifierKeyActive() was indeed the function I needed.