Shift (and ctrl) keyboard state gets "stuck" with ImGui

Hi there, I’m finding something weird. In my Cinder app that uses ImGui, I find the shift (and also ctrl) keyboard state can get “stuck”. I’ve traced through some of the code, and I found something strange…

When I press left shift, on the keyDown (ImGui_ImplCinder_KeyDown()) I have key code 304 being pressed down, and then the same code being released in keyUp (ImGui_ImplCinder_KeyUp()). When I press the right shift key, I get keyDown of 303, followed by a keyUp of 303, as expected. But it seems like there’s some sort of toggle, because the next time I press right shift key, I still get keyDown of 303 (as before), but the subsequent keyUp has code 304 (corresponding to left shift)! This means the internal io.KeysDown array gets messed up.

I see something similar with left/right control keys, I always get down/up codes of 306 for left ctrl, but for right ctrl I get down and up of code 305 one time, then down of 305 and up of 306 the next time I press/release.

There must be some weird remapping of right to left, but only every second time…? Can anybody reproduce this? I’m on Windows with a fairly recent master branch of Cinder.

Thanks,
Glen.

I haven’t figured out why we get this weird behaviour (where right shift/ctrl keys sometimes send different key codes on KeyDown vs KeyUp), but at least I solved my problems by using a better way of getting modifier state from ImGui. I now use this simpler condition:

ui::GetIO().KeyShift  // or KeyCtrl, as appropriate

rather than what I used to check:

ui::IsKeyDown(app::KeyEvent::KEY_LSHIFT) || ui::IsKeyDown(app::KeyEvent::KEY_RSHIFT)

So, my bad, I guess. (Although the down/up key code issue is still mysterious…)