0

I've been using QEvent::KeyPress only to emulate keypresses for navigating QTreeView and QTableView without explicitly releasing the keys afterwards. Works like a charm, no issue at all. For example

Class::moveFocus(double v) {
    const auto mod = (v > 0) ? Qt::NoModifier : Qt::ShiftModifier;
    const auto times = static_cast<unsigned short>(std::abs(v));
    QKeyEvent event = QKeyEvent{
            QEvent::KeyPress, Qt::Key_Tab, mod, QString(), false, times};
    QApplication::sendEvent(QApplication::focusWidget(), &event);
}

Recently though, I was experiencing issues which I unfortunately can't reproduce reliaby: it seems that after the event shown above the Shift got stuck (idk if it's due to a QDialog interfering the navigation, or some focus change).

Thus my question: Does a QEvent::KeyPress require a follow-up QEvent::KeyRelease to guarantee all modifiers are released? I did not find anything related in the official Qt docs.

ronso0
  • 1
  • 1

1 Answers1

0

I figured the issue can be avoided in the first place by using Qt::Key_BackTab (not Qt::Key_Tab + Qt::ShiftModifier) to move focus.

Besides, I couldn't resolve the issue with emulated Shift+Tab since this seems to be a special key combo: when pressing Shift+Tab on a real keyboard I observed that the current widget receives Shift press, and --after focus has changed-- the next widget receives BackTab release (and optionally Shift release). Might as well have to do with the apps keyEventFilter, even though that is just observing, not eating keyEvents. Idk..

For sake of completeness, this is the working piece of code:

Class::moveFocus(double v) {
    const auto key = (v > 0) ? Qt::Key_Tab : Qt::Key_BackTab;
    const auto times = static_cast<unsigned short>(std::abs(v));
    QKeyEvent event = QKeyEvent{
            QEvent::KeyPress, key, Qt::NoModifier, QString(), false, times};
    QApplication::sendEvent(QApplication::focusWidget(), &event);
}
ronso0
  • 1
  • 1