Keyboard patch: Fixes handling of F10 (Windows) and potential stuck keys
when a menu is open (all platforms but possibly only an issue on Windows).
Tested on Windows 10/64-bit only. I won't be providing a binary (for
various reasons) so you'll either have to patch the source and recompile or
wait for an official release.
diff -r b0e396f600d9 src/qt5/main_window.cpp
--- a/src/qt5/main_window.cpp Sat May 05 21:00:45 2018 +0100
+++ b/src/qt5/main_window.cpp Sat May 19 18:33:56 2018 +0100
@@ -421,6 +421,8 @@
void
MainWindow::keyPressEvent(QKeyEvent *event)
{
+ if (!accepting_kbd_input()) return ; // Block keyboard input (to
non-GUI elements) in problematic cases
+
// Special case, handle windows menu key as being menu mouse button
if(Qt::Key_Menu == event->key()) {
emit this->emulator.mouse_press_signal(Qt::MidButton);
@@ -485,6 +487,8 @@
void
MainWindow::keyReleaseEvent(QKeyEvent *event)
{
+ if (!accepting_kbd_input()) return ; // Block keyboard input (to
non-GUI elements) in problematic cases
+
// Special case, handle windows menu key as being menu mouse button
if(Qt::Key_Menu == event->key()) {
emit this->emulator.mouse_release_signal(Qt::MidButton);
@@ -501,6 +505,22 @@
}
}
+// Check if accepting keyboard input
+bool
+MainWindow::accepting_kbd_input()
+{
+ // Not accepting if any menus open (solves potential 'stuck key'
issues)
+ QList<QWidget *> menus = menuBar()->findChildren<QWidget *>() ;
+ QList<QWidget *>::const_iterator iter = menus.constBegin() ;
+ QList<QWidget *>::const_iterator iter_end = menus.constEnd() ;
+ while(iter < iter_end)
+ {
+ if ((*(iter++))->isVisible()) return false ;
+ }
+
+ return true ;
+}
+
void
MainWindow::menu_reset()
{
@@ -1208,8 +1228,8 @@
/**
* windows pre event handler used by us to modify some default behaviour
*
- * Disable the use of the virtual menu key (alt) that otherwise goes off
- * every time someone presses alt in the emulated OS
+ * Disable the use of ALT and F10 on the host which select the menubar
+ * every time they're pressed in the emulated OS
*
* @param eventType unused
* @param message window event MSG struct
@@ -1223,21 +1243,21 @@
Q_UNUSED(eventType);
MSG *msg = static_cast<MSG*>(message);
+
+ // Handle 'alt' and F10 key presses directly that would otherwise
select the menu
+ // Fake the key press and release and tell windows/qt to not handle it
+ if((msg->message == WM_SYSKEYDOWN || msg->message == WM_SYSKEYUP) &&
+ (msg->wParam == VK_MENU || msg->wParam == VK_F10))
+ {
+ BYTE scanCode = (BYTE) (msg->lParam >> 16) ;
- // Handle 'alt' key presses that would select the menu
- // Fake 'alt' key press and release and then tell windows/qt to
- // not handle it
- if((msg->message == WM_SYSKEYDOWN || msg->message == WM_SYSKEYUP)
- && (msg->wParam == VK_MENU))
- {
// Use the code from the qt key press and release handlers
- // 0x38 is the windows native keycode for alt
if(msg->message == WM_SYSKEYDOWN) {
- held_keys.insert(held_keys.end(), 0x38);
- emit this->emulator.key_press_signal(0x38);
+ held_keys.insert(held_keys.end(), scanCode);
+ emit this->emulator.key_press_signal(scanCode);
} else {
- held_keys.remove(0x38);
- emit this->emulator.key_release_signal(0x38);
+ held_keys.remove(scanCode);
+ emit this->emulator.key_release_signal(scanCode);
}
return true;
}
@@ -1245,4 +1265,4 @@
// Anything else should be handled by the regular qt and windows
handlers
return false;
}
-#endif // Q_OS_WIN32
+#endif // Q_OS_WIN32
\ No newline at end of file
diff -r b0e396f600d9 src/qt5/main_window.h
--- a/src/qt5/main_window.h Sat May 05 21:00:45 2018 +0100
+++ b/src/qt5/main_window.h Sat May 19 18:33:56 2018 +0100
@@ -155,6 +155,8 @@
void cdrom_menu_selection_update(const QAction *cdrom_action);
+ bool accepting_kbd_input() ;
+
bool full_screen;
bool reenable_mousehack; ///< Did we disable mousehack entering
fullscreen and have to reenable it on leaving fullscreen?
On Fri, May 18, 2018 at 11:29 PM, J Percival <[email protected]> wrote:
> I have a fix for the Windows F10 issue and another menu/keyboard related
> problem in the works but I want to test it a bit more and make sure I
> haven't broken anything in the process before posting it.
>
> Regards,
> James
>
> On Fri, May 18, 2018 at 6:12 PM, J Percival <[email protected]> wrote:
>
>> I've reproduced this. As Bryan says, it's a case of the emulated Shift
>> key getting stuck. This appears to happen when Shift is pressed at the same
>> time as accessing a menu (including 'File', 'Disc', etc). Why does
>> Shift-F10 do it? I think because that's the Windows shortcut for opening
>> the context menu (same as right-click by default).
>>
>> As a workaround, pressing Shift again will 'unstick' it.
>>
>>
>> On Fri, May 18, 2018 at 2:55 AM, Bryan Hogan <[email protected]>
>> wrote:
>>
>>> In message <db0911f756.old_coaster@old_coaster.yahoo.co.uk>
>>> Tony Moore <[email protected]> wrote:
>>>
>>> > Under RPCEmu 0.8.15, shift-f10 works as intended. However, under RPCEmu
>>> > 0.9.0, shift-f10 corrupts the filing system
>>>
>>> I think you are over dramatising that a bit! If it corrupted the
>>> filesystem then rebooting wouldn't help.
>>>
>>> > not possible to close an open file, or directory. Clicking on the close
>>> > icon causes the object to be iconised to the iconbar.
>>>
>>> That sounds like the Shift key status has become stuck On, so RISC OS
>>> thinks every click you do is a shift-click.
>>>
>>> It could be some accessibility feature that is intercepting the
>>> shift-F10 shortcut and "holding" the shift status, but I don't have
>>> Windows so can't check.
>>>
>>> Bryan.
>>>
>>> --
>>> RISC OS User Group Of London - http://www.rougol.jellybaby.net/
>>> RISC OS London Show - http://www.riscoslondonshow.co.uk/
>>>
>>> _______________________________________________
>>> Rpcemu mailing list
>>> [email protected]
>>> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>>>
>>
>>
>
_______________________________________________
Rpcemu mailing list
[email protected]
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
