Possible bug in juce.HWNDComponentPeer.doKeyDown (Windows)

Hi, I’m noticing that Component::keyStateChanged() does detect modifiers key up, but it doesn’t detect modifiers key down. Digging into the code I see in HWNDComponentPeer.doKeyDown (win32 version) you have this:

bool doKeyDown (const WPARAM key)
    bool used = false;

    switch (key)
        case VK_SHIFT:
        case VK_LSHIFT:
        case VK_RSHIFT:
        case VK_CONTROL:
        case VK_LCONTROL:
        case VK_RCONTROL:
        case VK_MENU:
        case VK_LMENU:
        case VK_RMENU:
        case VK_LWIN:
        case VK_RWIN:
        case VK_CAPITAL:
        case VK_NUMLOCK:
        case VK_SCROLL:
        case VK_APPS:
            // ##### HERE --> handleKeyUpOrDown (true) ???

        case VK_LEFT:
        // .... other cases....
        case VK_F24:
            used = handleKeyUpOrDown (true);
            used = handleKeyPress (extendedKeyModifier | (int) key, 0) || used;
       // .... more code ...

Shouldn’t be a call to handleKeyUpOrDown(true) there? Or maybe remove it from doKeyUp()?

And as request: if you could send with an extra argument which key is down or up, it would be perfect (including difference between L / R modifiers)

Yeah that seems like an omission, I’ll get it added. As for the second point, can you not use KeyPress::isKeyCurrentlyDown() to check which key’s state has changed inside the keyStateChanged() method?

Yes, I can do it, but it seems quite unefficient compare 70-80 commands per event (after all, it’s the windows hook that sends a lot of repetitions when holding a key). I do not use keyPressed, because I need the keyup event too.

Please consider it, shouln’t be too hard to do, but I hate to hack JUCE code. Also knowing if it is left or right modifier will help a lot.