QWidget objects with Qt::Window flag set do not pass on ignored events
-
Using Qt 5.6.0 on Windows 10.
After a fair amount of trouble and debugging, I discovered that if a QWidget is a window (has Qt::Window set), then it will not put ignored events back into the event loop.
I am creating a layout editor tool for work. There is the MainWindow, and that window can spawn other QWidget-derived windows, and each of those can have several QOpenGLWidget objects as children. I want to make the ESC key close the program (or do something at the MainWindow level), so I made each of my widgets overload keyPressEvent(...), and everyone ignores it except for MainWindow.
Problem: MainWindow never gets the key events if it has a child window as the focus.
The QOpenGLWidgets will, when ignoring an event, pass it on to their parents. But if the QOpenGLWidget has the Qt::Window flag set, then the parent QWidget-derived window will no longer receive the event. Unset Qt::Window flag and the parent again receives ignored events.
Is this a bug?
Note: I even tried overriding QObject's virtual event(QEvent *e) method, and that didn't get anything.
Also Note: The only way around right now is signals, which is a real pain when MainWindow has a family tree of widgets. -
Hi! It's not a bug. Anyways, you can hack around this without using signals, but be careful not to send the events around in an endless loop.
Add this to your MainWindow:
public: void dirtyHack(QKeyEvent *ev) { keyPressEvent(ev); }
And in your child widget (the one with the Qt::Window flag set), override keyPressEvent:
#include "mainwindow.h" void MyWindow::keyPressEvent(QKeyEvent *ev) { MainWindow *mainWindow = dynamic_cast<MainWindow*>(parentWidget()); mainWindow->dirtyHack(ev); }
By this you can indirectly call the protected keyPressEvent of the MainWindow. Not sure if that's a great idea but it seems to work. :-)
-
Or you could use a global event filter:
myfilter.h
#ifndef MYFILTER_H #define MYFILTER_H #include <QObject> class MyFilter : public QObject { Q_OBJECT public: explicit MyFilter(QObject *parent = 0); protected: virtual bool eventFilter(QObject *obj, QEvent *event) override; }; #endif // MYFILTER_H
myfilter.cpp
#include "myfilter.h" #include <QEvent> #include <QKeyEvent> #include <QDebug> MyFilter::MyFilter(QObject *parent) : QObject(parent) { } bool MyFilter::eventFilter(QObject *obj, QEvent *event) { if (event->type() == QEvent::KeyPress) { QKeyEvent *ke = static_cast<QKeyEvent*>(event); if (ke->key() == Qt::Key_Escape) { qDebug() << "Escape"; return true; } } return QObject::eventFilter(obj, event); }
main.cpp
#include "mainwindow.h" #include <QApplication> #include "myfilter.h" int main(int argc, char *argv[]) { QApplication a(argc, argv); MyFilter *myFilter = new MyFilter(&a); a.installEventFilter(myFilter); MainWindow w; w.show(); return a.exec(); }
-
@Wieland I tried that, but MainWindow will not receive key events when another window widget (that is, has the window flag
Qt::Window
set), or one of its non-window children, has the focus. Repeated experiments on my system all indicate that the state of being a window prevents any widgets upstream of it from receiving events, even those with global event filters.Another explanation?
In another post of mine, you pointed me to the framework developers. Should I try the "Interest" list?
-
@amdreallyfast Hmm.. the code I posted works for me. Can you post a minimal example? Maybe I haven't fully understood what you're trying to do. Regarding the mailing list: The problem here isn't a bug so no need to annoy the devs (yet) ;-)
-
@Wieland I'll try to get something put together in the next few days. I can't send code from my work computer to home, but I'll try to get something together.
-
Sorry for the delay.
Here's the basic program: The main window has a push button that summons a ChildWindow object (QOpenGLWidget derivative) with the Qt::Window flag set. Pressing any key causes the ChildWindow's keyPressEvent(...) to print a message to the console, and then the event is ignored. The main window is the ChildWindow's parent, so the event should pass on to the main window. But it doesn't. The event stops at the ChildWindow.
Did I miss something or is this a bug?
Here's my code.
.pro (note the "CONFIG+= console" at the end)
QT += core gui greaterThan(QT_MAJOR_VERSION, 4): QT += widgets TARGET = WidgetsEventsNotPropogating TEMPLATE = app SOURCES += main.cpp\ mainwindow.cpp \ childwindow.cpp HEADERS += mainwindow.h \ childwindow.h FORMS += mainwindow.ui CONFIG += console
mainwindow.ui XML
<?xml version="1.0" encoding="UTF-8"?> <ui version="4.0"> <class>MainWindow</class> <widget class="QMainWindow" name="MainWindow"> <property name="geometry"> <rect> <x>0</x> <y>0</y> <width>400</width> <height>300</height> </rect> </property> <property name="windowTitle"> <string>MainWindow</string> </property> <widget class="QWidget" name="centralWidget"> <widget class="QPushButton" name="pushButton"> <property name="geometry"> <rect> <x>140</x> <y>100</y> <width>171</width> <height>81</height> </rect> </property> <property name="text"> <string>PushButton</string> </property> </widget> </widget> <widget class="QMenuBar" name="menuBar"> <property name="geometry"> <rect> <x>0</x> <y>0</y> <width>400</width> <height>21</height> </rect> </property> </widget> <widget class="QToolBar" name="mainToolBar"> <attribute name="toolBarArea"> <enum>TopToolBarArea</enum> </attribute> <attribute name="toolBarBreak"> <bool>false</bool> </attribute> </widget> <widget class="QStatusBar" name="statusBar"/> </widget> <layoutdefault spacing="6" margin="11"/> <resources/> <connections/> </ui>
mainwindow.h
#include <QMainWindow> namespace Ui { class MainWindow; } class MainWindow : public QMainWindow { Q_OBJECT public: explicit MainWindow(QWidget *parent = 0); ~MainWindow(); private slots: void on_pushButton_clicked(); void keyPressEvent(QKeyEvent *e) override; private: Ui::MainWindow *ui; };
mainwindow.cpp
#include <qevent.h> #include "mainwindow.h" #include "ui_mainwindow.h" #include "childwindow.h" MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { ui->setupUi(this); } MainWindow::~MainWindow() { delete ui; } void MainWindow::on_pushButton_clicked() { printf("MainWindow::on_pushButton_clicked()\n"); ChildWindow *cw = new ChildWindow(this, Qt::Window); cw->show(); } void MainWindow::keyPressEvent(QKeyEvent *e) { printf("MainWindow::keyPressEvent(QKeyEvent *e)\n"); e->accept(); }
childwindow.h
#include <qopenglwidget.h> class ChildWindow : public QOpenGLWidget { Q_OBJECT public: ChildWindow(QWidget *parent = 0, Qt::WindowFlags f = Qt::WindowFlags()); protected: void keyPressEvent(QKeyEvent *e); };
childwindow.cpp
#include <qevent.h> #include "childwindow.h" ChildWindow::ChildWindow(QWidget *parent, Qt::WindowFlags f) : QOpenGLWidget(parent, f) { } void ChildWindow::keyPressEvent(QKeyEvent *e) { printf("ChildWindow::keyPressEvent(QKeyEvent *e)\n"); e->ignore(); }
-
Hi!
I still don't think it's a bug but intended behaviour. However, in the meantime I came up with another workaround which is much prettier than the ones before: Just do the following:#include <QApplication> // ... void ChildWindow::keyPressEvent(QKeyEvent *e) { printf("ChildWindow::keyPressEvent(QKeyEvent *e)\n"); QApplication::sendEvent(parentWidget(), e); e->ignore(); }
-
Override
QWidget::event
and inspect what the state of the event is after the call to the superclass' method. E.g:#include <qopenglwidget.h> class ChildWindow : public QOpenGLWidget { Q_OBJECT public: // ... bool event(QEvent * e) override { bool result = QOpenGLWidget::event(e); qDebug() << result << e->isAccepted(); return result; } };
Then report your findings here. In principle
QWidget::event
should propagate the event up the object tree. While I don't believe this should be dependent on the window flags, I'm not sure.Kind regards.
-
@kshegunov As far as I can tell the docs mention nothing about this. On the other hand google finds a handful of people stuggling with this dating back half a decade or so. Maybe it's time to read some code :-|
-
@kshegunov And yes, the base class implementation returns true although the event hasn't been accepted. So, to me, still looks as this happens on purpose.
-
-
@Wieland said in QWidget objects with Qt::Window flag set do not pass on ignored events:
As far as I can tell the docs mention nothing about this.
-
@kshegunov I meant it doesn't say anything about event propagation stopping on window boundaries.
-
@Wieland said in QWidget objects with Qt::Window flag set do not pass on ignored events:
I see. Have you confirmed this is because of the flag? I'm not as convinced. I didn't see anything in the code to hint that the flags have any reflection on events propagation. I'd expect the same behavior (key presses not bubbling up) for any window flag that may be passed. -
@kshegunov Flags have some effect, e.g. the popup flag makes the window close on key pressed and then the event is accepted; but otherwise: no. The keyPressEvent() function doesn't do anything but ignore the event and then in the end event() returns true. Maybe there's more magic in the event dispatcher, but the code is quite hard to read.
Edit: Key event propagation actually does work as expected with flag Qt:Widget on the child and when the event is being ignored. But I can't tell where the magic happens :-/
-
Sorry, I give up. :-/
-
Thanks anyway.
BTW, @kshegunov , I did experiment with overriding the Qt::event(...) method, and MainWindow was still getting nothing as long as the child widget was a window. Then I made the child not spawn as a window (instead as a sub-widget) and the ignored event was passed on just fine. For the time being, I'll just click on MainWindow and hit Esc. to close down the program. I don't want to deal with connecting everyone to the MainWindow via signal and slot just to tell it to close.
-
@amdreallyfast said in QWidget objects with Qt::Window flag set do not pass on ignored events:
I did experiment with overriding the Qt::event(...) method, and MainWindow was still getting nothing as long as the child widget was a window. Then I made the child not spawn as a window (instead as a sub-widget) and the ignored event was passed on just fine.
My best advice is to ask in the mailing list if this is intentional, and if it's not to file a bug report.
-
By "mailing list" do you mean the "interest" mailing list? I've already asked one question there and gotten no replies. It is quite busy with "how do I do this?" messages instead of unexpected behavior, so I don't know if I'm asking the right group.