I'm pretty sure I was able to use OpenMPT over RDP before, but that was from another Windows client. Maybe your iOS RDP client indeed synthesizes higher-level keyboard events (WM_CHAR probably) than what is required (WM_KEYDOWN/WM_KEYUP). Unfortunately WM_CHAR wouldn't really be a suitable alternative for OpenMPT's keyboard handling so I'm not really sure what could be done here apart from trying a different RDP client.

It's the official Microsoft Remote Desktop client for iOS, and I haven't encountered this issue with any other Windows apps, so I don't think the explanation can be quite that simple.

Is there any key event logging I can enable, or do you have a build with matching symbols I can use to set up some tracepoints with Visual Studio?

I found this elsewhere online:

When I analyzed the incoming keystrokes on a remote Windows system, I saw the iOS RD client was sending
ASCII/Unicode values for the alphanumeric keys, whereas other Microsoft RD clients were sending the proper BIOS keyboard scan codes instead. Most Windows apps understood what was going on and adjusted accordingly, but VMware did not.

There doesn't appear to be a way for the user to correct this annoying behavior within iOS or in the client app.

And elsewhere, I found this:

We switched from sending scan codes to unicodes with 8.1.x.

We did this because the many issues customers were having with mismatched keyboard layouts. This was especially bad on mobile devices where the input to our app is unicode and we needed to translate to scancodes based on the remote side’s keyboard layout. Often there would be a mismatch as the protocol does not allow detecting the remote side keyboard nor set it except for a new login.

We have talked about offering scan codes again in the future as an option users can set. In the meantime (not soon) they can use the remote side keyboard (osk).

Most notably: arrow keys work for navigating around inside the pattern editor, none of the alphnumeric keys work, which seems to support the “scan codes versus unicode” explanation.

It sounds like what iOS RDP sends are “virtual key codes” instead of the “scan codes” that would normally generate them. And sure enough, OpenMPT’s general key input handling relies entirely upon scancodes: https://github.com/OpenMPT/openmpt/blob/e0cdb885c09d888e14b03789762fd7743f580ee7/mptrack/InputHandler.cpp#L109

It looks like that function could/should additionally check wParam for WM_KEYUP and/or WM_KEYDOWN, rather than trying to identify keyup/keydown events exclusively by examinng the code value.

typo correction: by examining the scancode value

I don't think that should be required; CViewPattern::PreTranslateMessage should be the code path handling virtual key codes. The keyboard hook (which calls CInputHandler::GeneralKeyEvent) is used for global shortcuts, not view-specific shortcuts.

Is there any key event logging I can enable

No.

or do you have a build with matching symbols I can use to set up some tracepoints with Visual Studio?

Debug symbols for all official releases are available at https://download.openmpt.org/archive/.symbols/

I downloaded and installed VS2022 and Win10SDK last night and successfully built and began debugging. The message being produced by the keypress from the iOS RDP app is VK_PACKET. That's about as far as I got before running out of steam for the night, but I'll keep digging.

In this repro, the key I pressed on the iPad was z. Call stack of interest:

>   OpenMPT.exe!CInputHandler::GeneralKeyEvent(InputTargetContext context=kCtxAllContexts, int code=0x00000000, unsigned __int64 wParam=0x00000000000000e7, __int64 lParam=0x0000000000000001) Line 110 C++
    OpenMPT.exe!CMainFrame::KeyboardProc(int code=0x00000000, unsigned __int64 wParam=0x00000000000000e7, __int64 lParam=0x0000000000000001) Line 507   C++
    user32.dll!00007ffa002c0e62()   Unknown
    user32.dll!00007ffa002be3e9()   Unknown
    user32.dll!00007ffa002be2de()   Unknown
    ntdll.dll!00007ffa01430ef4()    Unknown
    win32u.dll!00007ff9ff181104()   Unknown
    user32.dll!00007ffa002c1b7e()   Unknown
    OpenMPT.exe!AfxInternalPumpMessage() Line 153   C++
    OpenMPT.exe!CWinThread::PumpMessage() Line 900  C++
    OpenMPT.exe!CWinThread::Run() Line 629  C++
    OpenMPT.exe!CWinApp::Run() Line 787 C++
    OpenMPT.exe!CTrackApp::Run() Line 1550  C++
    OpenMPT.exe!AfxWinMain(HINSTANCE__ * hInstance=0x00007ff76be80000, HINSTANCE__ * hPrevInstance=0x0000000000000000, wchar_t * lpCmdLine=0x0000027e8dc73064, int nCmdShow=0x0000000a) Line 47 C++
    OpenMPT.exe!wWinMain(HINSTANCE__ * hInstance=0x00007ff76be80000, HINSTANCE__ * hPrevInstance=0x0000000000000000, wchar_t * lpCmdLine=0x0000027e8dc73064, int nCmdShow=0x0000000a) Line 26   C++
    OpenMPT.exe!invoke_main() Line 123  C++
    OpenMPT.exe!__scrt_common_main_seh() Line 288   C++
    OpenMPT.exe!__scrt_common_main() Line 331   C++
    OpenMPT.exe!wWinMainCRTStartup(void * __formal=0x0000009681a57000) Line 17  C++
    kernel32.dll!00007ff9ff867034() Unknown
    ntdll.dll!00007ffa013e26a1()    Unknown

The message is: WM_KEYDOWN (wParam==0xe7==VK_PACKET, lParam==0x1).

According to the MSDN docs, when the stack unwinds back to AfxInternalPumpMessage and passes this message into TranslateMessage, that API should post a corresponding WM_CHAR to the message queue.

But before that can happen, another PreTranslateMessage handler gets a shot at it:

>   OpenMPT.exe!CInputHandler::KeyEvent(InputTargetContext context=kCtxViewPatternsNote, unsigned int & nChar=0x000000e7, unsigned int & __formal=0x00000001, unsigned int & nFlags=0x00000000, KeyEventType keyEventType=kKeyEventDown, CWnd * pSourceWnd=0x0000000000000000) Line 147 C++
    OpenMPT.exe!CViewPattern::PreTranslateMessage(tagMSG * pMsg=0x0000027e8dc7f1b8) Line 665    C++
    OpenMPT.exe!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x0000000000080b3c, tagMSG * pMsg=0x0000027e8dc7f1b8) Line 3379    C++
    OpenMPT.exe!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x0000027e8dc7f1b8) Line 233   C++
    OpenMPT.exe!CWinThread::PreTranslateMessage(tagMSG * pMsg=0x0000027e8dc7f1b8) Line 778  C++
    OpenMPT.exe!AfxPreTranslateMessage(tagMSG * pMsg=0x0000027e8dc7f1b8) Line 252   C++
    OpenMPT.exe!AfxInternalPumpMessage() Line 178   C++
    OpenMPT.exe!CWinThread::PumpMessage() Line 900  C++
    OpenMPT.exe!CWinThread::Run() Line 629  C++
    OpenMPT.exe!CWinApp::Run() Line 787 C++
    OpenMPT.exe!CTrackApp::Run() Line 1550  C++
    OpenMPT.exe!AfxWinMain(HINSTANCE__ * hInstance=0x00007ff76be80000, HINSTANCE__ * hPrevInstance=0x0000000000000000, wchar_t * lpCmdLine=0x0000027e8dc73064, int nCmdShow=0x0000000a) Line 47 C++
    OpenMPT.exe!wWinMain(HINSTANCE__ * hInstance=0x00007ff76be80000, HINSTANCE__ * hPrevInstance=0x0000000000000000, wchar_t * lpCmdLine=0x0000027e8dc73064, int nCmdShow=0x0000000a) Line 26   C++
    OpenMPT.exe!invoke_main() Line 123  C++
    OpenMPT.exe!__scrt_common_main_seh() Line 288   C++
    OpenMPT.exe!__scrt_common_main() Line 331   C++
    OpenMPT.exe!wWinMainCRTStartup(void * __formal=0x0000009681a57000) Line 17  C++
    kernel32.dll!00007ff9ff867034() Unknown
    ntdll.dll!00007ffa013e26a1()    Unknown

0xe7 (VK_PACKET) is getting passed into CInputHandler::KeyEvent as the value for nChar, which seems fishy at best, but nothing down this execution path chooses to handle the message, so the stack unwinds back to the pump, and TranslateMessage gets called.

As expected, a few message pumps later, I see GetMessage pull this out of the queue: message==0x102==WM_CHAR, (wParam==0x7a, lParam==0x1)

But neither CInputHandler::GeneralKeyEvent nor CInputHandler::KeyEvent ever get called for WM_CHAR, because it's not a keyboard event.

Interesting remarks from https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-keybdinput:

INPUT_KEYBOARD supports nonkeyboard-input methods—such as handwriting recognition or voice recognition—as if it were text input by using the KEYEVENTF_UNICODE flag. If KEYEVENTF_UNICODE is specified, SendInput sends a WM_KEYDOWN or WM_KEYUP message to the foreground thread's message queue with wParam equal to VK_PACKET. Once GetMessage or PeekMessage obtains this message, passing the message to TranslateMessage posts a WM_CHAR message with the Unicode character originally specified by wScan. This Unicode character will automatically be converted to the appropriate ANSI value if it is posted to an ANSI window.

It sounds like this might be a viable approach:

Modify CViewPattern::PreTranslateMessage to handle VK_PACKET by explicitly calling TranslateMessage on it to post the corresponding WM_CHAR message to the queue, then immediately call PeekMessage to remove the most recently-posted WM_CHAR message from the queue and extract its character code, repost that message back to the queue using PostMessage, then call VkKeyScanEx to convert the character code to a virtual key code, and then finally pass that value (rather than VK_PACKET) for wParam down into the rest of the usual WM_KEYDOWN/WM_SYSKEYDOWN/WM_KEYUP/WM_SYSKEYUP handling.

Thoughts?

The alternative would be to rewrite all the existing keyboard handling to use "Raw Input": https://learn.microsoft.com/en-us/windows/win32/inputdev/about-raw-input

Handling VK_PACKET by using TranslateMessage and PeekMessage(PM_NOREMOVE) works. Not sure what else it might regress, but it definitely resolves my repro. I'll push a MR to you in GitHub.

PR created: https://github.com/OpenMPT/openmpt/pull/12

Thanks, I can see that the same issue exists with the Windows on-screen keyboard, so I can round off the patch (e.g. by extending it to cover the other views such as sample and instrument editor) without RDP.

Edit: No, I was wrong, the on-screen keyboard is fine. I was just testing the wrong pattern column...

This should be fixed as of r18129 in all views, not just pattern view.

Awesome, thanks!