ModifierKeys::getCurrentModifiers().isAltDown() does not work for the right alt in Windows.
I checked the updateKeyModifiers() in juce_win32_Windowing:
static void updateKeyModifiers() noexcept
{
int keyMods = 0;
if (isKeyDown (VK_SHIFT)) keyMods |= ModifierKeys::shiftModifier;
if (isKeyDown (VK_CONTROL)) keyMods |= ModifierKeys::ctrlModifier;
if (isKeyDown (VK_MENU)) keyMods |= ModifierKeys::altModifier;
if (isKeyDown (VK_RMENU)) keyMods &= ~(ModifierKeys::ctrlModifier | ModifierKeys::altModifier);
currentModifiers = currentModifiers.withOnlyMouseButtons().withFlags (keyMods);
}
VK_MENU = both right / left alt - this if statement is working well.
VK_RMENU = just the right alt - this if statement is the one causing the bug, once I commented it out the right alt was detected fine.
The thing is, I don’t quite understand what the VK_RMENU if statement actually does do I guess commenting it out caused other bugs.
This is really really old code, and I can’t remember all the subtleties of it, but there was definitely some kind of weird behaviour when you press the right alt key… You’re right to assume that commenting it out will cause problems, but I wish I could remember why…!
I think it was because right-alt can be simulated by pressing alt+ctrl, and when the event arrived, the OS was faking those keys (or something like that).
This specific line is still here, and it's still causing the right alt key to not be treated at all... it's annoying for right hand plugin users for example.
The default behaviour in windows is to treat right alt like it's a ctrl+alt, so even if the OS is faking those keys when someone is pressing right alt, what's wrong with that? I think it's just worse to discard everything.
The reason it's there is because if it leaves the ctrl modifier in there, then keypresses using just the right alt key won't be recognised correctly. Not sure I could remove it without fearing breaking people's code..
The behaviour of right-Alt depends on your keyboard layout.
Some layouts, especially those used for languages with a lot of accented letters, often have an AltGr key instead of a right Alt. In these layouts holding the AltGr key down is equivalent to holding Ctrl+Alt down.
For example on an AZERTY keyboard used in Belgium, you have three symbols on a lot of keys. For instance, the 1 key has:
1
$
|
AltGr is the third shift state (it's shorthand for alternate graph). To type a pipe character, you use AltGr + 1. Using Ctrl + Alt + 1 will also produce a pipe character. And pressing AltGr will have a different effect than pressing Alt, more specifically it will normally not activate the menu.
On a standard QUERTY layout, right Alt and left Alt mean the same and both will activate the menu.
I'd say that this deserve some test, to at least be sure about why and how this line came here and what's the risk of removing it.
At the very least we should have another way to know if this specific key is pressed (maybe a specific flag in the key modifier?). It would be sad if the only way to know if the right alt key is press on windows would be to use OS call...
