I'm a newcomer to Qt, but I'm trying to implement what basically amounts to a video-game-esque input loop in a Qt application (crazy, I know, but see if you can help). I need accurate, one-to-one event handling for key presses and key releases, for all keys, including modifiers, no matter how weirdly you chord-up the keyboard.
Of course, your main access to key events is through QKeyEvent. But let's say the following happens:
- user presses and holds Ctrl
- user presses and holds Up
- user releases Ctrl and Up simultaneously
As far as I can tell, what I get from Qt is:
- QKeyEvent for the pressing of Ctrl, by itself (
Qt::Key_Ctrl)
- QKeyEvent for the pressing of Up, by itself (
Qt::Key_Up)
- QKeyEvent for the releasing of Ctrl+Up, with
key() == Qt::Key_Up and the Ctrl bit reflected in a modifier change.
This may be not exactly accurate, but it's my best guess as to what's going on from way too much debugging of the issue. In any event, the key release events when modifiers are involved are incredibly unreliable.
The Ctrl+Up sequence there at the end is the problem. Now, I know I'm getting modifier state in e->modifiers(), and I'm getting the key press in e->key(). I could do some complicated hacks, trying to remember the modifier state internally, to detect when the user's released the modifier. But then, the Qt docs inform me, speaking of e->modifiers(), that:
This function cannot always be trusted. The user can confuse it by pressing both Shift keys simultaneously and releasing one of them, for example.
This is exactly the case I'm trying to avoid.
Is there any reliable way to keep track of one-to-one key presses and releases, for both normal and modifier keys, in Qt? If not, what's the closest you can get?
EDIT: I can refine this a little bit. It seems that if you hold down Cmd on a Mac, press a few keys (letter keys, say), release them, then release Cmd, you don't get release events for the letter key releases. I'm going to try to isolate a small example and see if this is actually a Qt bug.
phyatt :
I think if you are getting very specific with the keyboard, you are going to have leave Qt and get something that is OS specific, or you need to handle the Qt events before any filtering happens.\n\nHandle Qt Events Before Filtering\n\nAccelerators in Qt look for and wait on Alt+__ combos and you can set up Ctrl+__ combos to be listened to by QAction.\n\nBoth of these types of Objects built into QApplication and the general GUI environment, might be interrupting the messages you are getting, and giving you less than what you are expecting.\n\nQt Documentation: The Event System ... this part has a link to this...\n\nQCoreApplication::notify() ... which tells the highest level that a Qt Application can be written to handle input using the Qt API:\n\n\n Installing an event filter on QCoreApplication::instance(). Such an event filter is able to process all events for all widgets, so it's just as powerful as reimplementing notify(); furthermore, it's possible to have more than one application-global event filter. Global event filters even see mouse events for disabled widgets. Note that application event filters are only called for objects that live in the main thread.\n\n\nOS Specific Keyboard Handling Alternative\n\nIf looking at debug statements from a Qt event filter installed at the level mentioned above yields the same results as what you mentioned in your question, then you will need to go to the OS specific keyboard input stuff. For example in Windows you would need to scan the keyboard and or look at the VK state of the whole keyboard and do something with it (with something like GetKeyboardState() ).",
2012-06-14T02:50:34