Shift + number (not from numpad)

Is there a way to detect Shift + <number_from_the_row_above_the_letters_so_not_numpad> on OSX?

I can’t find any. Even though raw NS key events signal the same keycode whether shift is pressed or not, e.g. keycode 0x14 for the number 3, with JUCE the keycode is 51 without shift, and altered to 35 when shift is pressed (which typically matches the ‘#’ character).

On Windows I can handle this issue without problems. There the keycode stays the same whether shift is pressed or not.

You can check the KeyPress keyCode value


That’s the thing, the keyCode is altered to become that of e.g. a # in the case of number 3. It doesn’t give me the unmodified one, like on Windows. Here’s a comparison example, OSX on the left, Windows on the right.

Hmm… if I put a break point and watch the Keypress keyCode value… I get:

Keyboard zero: 48
Shift Keyboard zero: 41 (open parentheses)

Numeric Zero: 196640
Shift Numeric Zero: 196640

Obviously the latter is the same… you need to use KeyPress::getModifiers() to check for the ModifierKeys


I don’t see how getModifiers() is going to help me. Like you stated, a keyboard zero’s keycode is 48 without shift, 41 with shift. On Windows I can’t reproduce that behaviour. And it’s the keyboard keys I want to use, not the numeric keypad.

Well if you get a keyCode of 41 and the ModifierKeys show the Shift key is down… that would indicate a Shift+0

You’d have to test with different keyboards and languages to ensure the keyCode is consistent though.

Windows uses keyboard scan codes which are different to MacOS


I’ve thought of that, but I thought it a quirky solution.

If I look at the native behaviour, it seems consistent between OSX and Windows. I.e. keycodes that NS and Win32 event messages provide are not different, whether shift is pressed or not.

I’m considering to circumvent whatever JUCE is doing to the keycodes and just handle things in my own code. I used to use raw keycodes as provided by the OS, in combination with and I was able to get very consistent behaviour like that.

Or maybe I can add some exceptions or conversion somewhere in/around But I’d have to study the code more.