Keypress keycode mismatch in Windows and Mac

Hi Jules,
When Ctrl + Shift + ‘>’ is pressed.
In windows we get keycode as 46(which represents ‘.’) but in Mac we get keycode as 62(which represents ‘>’).

Even if i do uppercase or lowercase result is same…

Basically my requirement is i need to handle 'Ctrl + Shift + >", should i put the “or” condition for ‘.’ and ‘>’ so that it will work in PC as well as in Mac. or is there any other way …

Remember that this isn’t just a mac/pc difference, people will inevitably have different, weird keyboards with strange layouts. There’s no way that every keyboard in the world will have ‘.’ and ‘<’ on the same key.

I think the best policy is to avoid hard-wiring “difficult” keypresses like this, and stick to number and letter keys. But let the user select their own keypresses if they want to, because they’ll be doing that on the keyboard they’re actually using, so whatever they pick will always work.

I was looking into the same issue of why key combos involving the shift key display differently on the PC and Mac, and stumbled upon this post (my apologies for reviving it!). I thought this might be useful for anyone else arriving here though.

I tracked the issue down to the following native file in the JUCE API:

juce_mac_NSViewComponentPeer.mm

From line 1244 it’s using the

#if JUCE_SUPPORT_CARBON

to wrap the code that will convert from what it calls a keyCode back to a text character.

Carbon support is turned off out of the box (since it is mostly deprecated that makes sense), so this conversion never happens. If I remove the #if it works fine on macOs Big Sur.

It got me wondering why these methods are still available if they’ve been deprecated, so I looked a bit deeper into the macOs system method calls like ‘TISGetInputSourceProperty’ and found that they are defined with:

AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER

in Carbon/Frameworks/HIToolBox/TextInputSources.h

Is it possible that

#if JUCE_SUPPORT_CARBON

could be removed from this keyCode conversion code since these methods are still supported?