While making some keyboard mappings and keyboard shortcuts in my program, I noticed two weird quirks with the KeyPress handling, one in Windows and one in Linux
In Windows the function isKeyCurrentlyDown() ignores the key state of ‘=’ and ‘\’. Normally the obvious workaround would be to just use ‘+’ and ‘|’, respectively, but I use the integer value of those characters for the rest of my function (a 2.5 octave computer key to midi map in the style of Pro/Fast/Impulse tracker) so I need to check those if the keys for those specific characters are down
I was able to create a workaround by modifying the source code of isKeyCurrentlyDown() in juce_Windowing_windows.cpp to this:
bool KeyPress::isKeyCurrentlyDown (const int keyCode)
{
auto k = (SHORT) keyCode;
if ((keyCode & extendedKeyModifier) == 0)
{
if (k >= (SHORT) 'a' && k <= (SHORT) 'z')
k += (SHORT) 'A' - (SHORT) 'a';
// Only translate if extendedKeyModifier flag is not set
const SHORT translatedValues[] = { (SHORT) ',', VK_OEM_COMMA,
(SHORT) '+', VK_OEM_PLUS,
(SHORT) '=', VK_OEM_PLUS,
(SHORT) '-', VK_OEM_MINUS,
(SHORT) '.', VK_OEM_PERIOD,
(SHORT) ';', VK_OEM_1,
(SHORT) ':', VK_OEM_1,
(SHORT) '/', VK_OEM_2,
(SHORT) '?', VK_OEM_2,
(SHORT) '[', VK_OEM_4,
(SHORT) ']', VK_OEM_6 };
for (int i = 0; i < numElementsInArray (translatedValues); i += 2)
if (k == translatedValues[i])
k = translatedValues[i + 1];
/* US keyboards use VK_OEM_5, non-US 102-key keyboards use VK_OEM_102 */
if (k == (SHORT) '\\') k = VkKeyScanA(k);
}
return HWNDComponentPeer::isKeyDown (k);
}
But I wanted to check and see if there’s a better workaround so I don’t have to overwrite this file or recopy the modified code every time I update JUCE, or if this is the only way to actually get around it while still using those characters
This bug isn’t present in Linux but while writing keyboard shortcuts for the numpad in Ubuntu 20.04, I discovered that getKeyCode() for the numpad doesn’t return a KeyPress::numberPad# value but rather returns the same char value as its respective number in the number row. Haven’t found a workaround for this one yet but if anyone knows of one, that’d be greatly appreciated ![]()
