I am having an issue trying to get a parent object to filter child events.
In the following example, I set up an event filter on a spin box. The event filter detects mouse press events on the spin box. I would then like the parent object to accept or ignore that event, based on some criteria.
The problem is that it seems to accept the mouse press event and then ignore the mouse release event. This is an issue with mouse wheel events.
How can I have my parent accept/ignore the event?
In the real case, the message has to be passed through more layers, but the behavior is the same. If you click the up arrow on the spin box, the message will popup and then the numbers will start spinning.
Qt version: 5.6.1
#include "mainwindow.h"
#include <QEvent>
#include <QSpinBox>
#include <QHBoxLayout>
#include <QMessageBox>
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent)
{
QSpinBox* spinner = new QSpinBox;
QHBoxLayout* layout = new QHBoxLayout;
QWidget* widget = new QWidget;
layout->addWidget(spinner);
spinner->installEventFilter(this);
connect(this, SIGNAL(mouse_pressed(QEvent*)),
this, SLOT(handle_event(QEvent*)));
widget->setLayout(layout);
setCentralWidget(widget);
}
MainWindow::~MainWindow()
{
}
bool MainWindow::eventFilter(QObject *watched, QEvent *event)
{
if (event->type() == QEvent::MouseButtonPress
event->type() == QEvent::Wheel)
{
emit mouse_pressed(event);
}
return QMainWindow::eventFilter(watched, event);
}
void MainWindow::handle_event(QEvent* event)
{
event->ignore();
QMessageBox(QMessageBox::Warning, "warning", "ignoring event").exec();
}
Edit 1: I have found a way to partially stop the event cascade. In MainWindow::handle_event(...), rather than calling 'event->ignore()', I call 'event->setAccepted(false)', then check for for 'event->isAccepted()' in the eventFilter. If it is not accepted, I ignore the event.
This solution has worked well for QLineEdit, but it is still not working as expected with QSpinBox and QPushbutton. For QSpinBox, a wheel event still changes the value and clicking the spin buttons result in sustained spinning (no mouse release being detected). For QPushButton, the event is ignored but the button stays depressed.
Edit 2: Returning false after ignoring the event blocks the cascade. Thanks #G.M. for the hint! I will post an answer.
The way to get the parent to decide whether or not a child should handle an event was to call 'event->setAccepted(false)', the check for the in the eventFilter function. If it is false, ignore the event and return true from the function.
Return true from the eventFilter function was counterintuitive to me, but its right there in the documentation. Event filters are much less invasive than subclassing, so I was glad to come to a solution.
#include "mainwindow.h"
#include <QEvent>
#include <QSpinBox>
#include <QHBoxLayout>
#include <QMessageBox>
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent)
{
QSpinBox* spinner = new QSpinBox;
QHBoxLayout* layout = new QHBoxLayout;
QWidget* widget = new QWidget;
layout->addWidget(spinner);
spinner->installEventFilter(this);
connect(this, SIGNAL(mouse_pressed(QEvent*)),
this, SLOT(handle_event(QEvent*)));
widget->setLayout(layout);
setCentralWidget(widget);
}
MainWindow::~MainWindow()
{
}
bool MainWindow::eventFilter(QObject *watched, QEvent *event)
{
if (event->type() == QEvent::MouseButtonPress
event->type() == QEvent::Wheel)
{
emit mouse_pressed(event);
if (!event->isAccepted())
{
event->ignore();
return true;
}
}
return QMainWindow::eventFilter(watched, event);
}
void MainWindow::handle_event(QEvent* event)
{
event->setAccepted(false);
QMessageBox(QMessageBox::Warning, "warning", "ignoring event").exec();
}
Related
I have a MainWindow with a non-modal QDialog and a QPushButton just for the purpose of showing the dialog. When the application is minimised and maximised again, I want the dialog, if visible, to regain keyboard focus.
Here is the code:
mainwindow.h
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
class MainWindow : public QMainWindow
{
Q_OBJECT
QDialog *dialog;
public:
explicit MainWindow(QWidget *parent = nullptr);
};
#endif // MAINWINDOW_H
mainwindow.cpp
#include "mainwindow.h"
#include <QPushButton>
#include <QDialog>
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
dialog(new QDialog(this))
{
QPushButton *button = new QPushButton("show dialog", this);
connect(button, &QPushButton::clicked, dialog, &QDialog::show);
setCentralWidget(button);
}
Sounds very simple but I have tried various approaches without any luck:
Approach 1:
Listen to QApplication::applicationStateChanged() signal and set focus to dialog when application state becomes active.
Approach 2:
Listen to dialog's show and window activate events and setting focus when triggered.
Approach 3:
Listen to main window's show and window activate events and setting focus when triggered.
Here is the code with the above approaches implemented:
mainwindow.h
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
class MainWindow : public QMainWindow
{
Q_OBJECT
QDialog *dialog;
public:
explicit MainWindow(QWidget *parent = nullptr);
virtual bool event(QEvent *event) override;
virtual bool eventFilter(QObject *watched, QEvent *event) override;
};
#endif // MAINWINDOW_H
mainwindow.cpp
#include "mainwindow.h"
#include <QPushButton>
#include <QDialog>
#include <QEvent>
#include <QApplication>
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
dialog(new QDialog(this))
{
QPushButton *button = new QPushButton("show dialog", this);
connect(button, &QPushButton::clicked, dialog, &QDialog::show);
setCentralWidget(button);
dialog->installEventFilter(this);
//set focus on dialog when app becomes active
connect(qApp, &QApplication::applicationStateChanged, this, [this](Qt::ApplicationState state){
if (dialog->isVisible() && state == Qt::ApplicationActive) {
dialog->setFocus();
}
});
}
bool MainWindow::event(QEvent *event)
{
//set focus on dialog when main window is shown or activated
if (event->type() == QEvent::Show || event->type() == QEvent::WindowActivate) {
if (dialog->isVisible()) {
dialog->setFocus();
}
}
return QMainWindow::event(event);
}
bool MainWindow::eventFilter(QObject *watched, QEvent *event)
{
//set focus on dialog when dialog is shown or activated
if (watched == dialog) {
if (event->type() == QEvent::Show || event->type() == QEvent::WindowActivate) {
dialog->setFocus();
}
}
return QMainWindow::eventFilter(watched, event);
}
An approach that works is listening to the QApplication::applicationStateChanged() signal and calling QWindow::requestActivate() when app becomes active:
connect(qApp, &QApplication::applicationStateChanged, this, [this](Qt::ApplicationState state){
if (dialog->isVisible() && state == Qt::ApplicationActive) {
if (dialog->windowHandle()) dialog->windowHandle()->requestActivate();
}
});
Not sure why QWindow::requestActivate() works but QWidget::setFocus() doesn't when both functions are supposed to give keyboard focus, according to the docs. If anyone knows please comment below.
I have this very strange issue regarding a QMenu and its position when execing.
Here is the code for my subclassed QMenu:
DockItemContextMenu::DockItemContextMenu(QWidget *parent) : QMenu(parent){
style = qApp->style();
QPointer<QAction> restoreAction = new QAction(QIcon(style->standardIcon(QStyle::SP_TitleBarMaxButton)), "Restore", this);
QPointer<QAction> minimizeAction = new QAction(style->standardIcon(QStyle::SP_TitleBarMinButton), "Minimize", this);
QPointer<QAction> maximizeAction = new QAction(style->standardIcon(QStyle::SP_TitleBarMaxButton), "Maximize", this);
QPointer<QAction> stayOnTopAction = new QAction("Stay On Top", this);
stayOnTopAction->setCheckable(true);
QPointer<QAction> closeAction = new QAction(style->standardIcon(QStyle::SP_TitleBarCloseButton), "Close", this);
this->addActions({restoreAction, minimizeAction, maximizeAction, stayOnTopAction, closeAction});
connect(restoreAction, &QAction::triggered, parent, [this](){ emit restoreTriggered();}, Qt::QueuedConnection);
connect(minimizeAction, &QAction::triggered, parent, [this](){ emit minimizeTriggered();}, Qt::QueuedConnection);
connect(maximizeAction, &QAction::triggered, parent, [this](){ emit maximizeTriggered();}, Qt::QueuedConnection);
connect(stayOnTopAction, &QAction::triggered, parent, [this](){ emit stayOnTopTriggered();}, Qt::QueuedConnection);
connect(closeAction, &QAction::triggered, parent, [this](){ emit closeTriggered();}, Qt::QueuedConnection);
}
Okay, so essentially I have another widget who holds an instance of this DockItemContextMenu as a field. In this owning class, called Titlebar, I made it such that doing a right click will emit the customContextMenuRequested(QPoint) signal.
TitleBar::TitleBar(QString title, QWidget *parent){
...
this->setContextMenuPolicy(Qt::CustomContextMenu);
contextMenu = new DockItemContextMenu(this);
connect(this, SIGNAL(customContextMenuRequested(QPoint)), this, SLOT(showContextMenu(QPoint)), Qt::QueuedConnection);
...
}
After this, this widget is essentially inserted into a QGraphicsScene and is converted implicitly into a QGraphicsItem. When I do the FIRST right click event on my Titlebar it will not exec at the correct screen position if I dragged the MainWindow of the entire QApplication anywhere other than its starting position on screen. In addition to being in a QGraphicsScene, this scene itself is always stored in a QSplitter. Now I would understand if this always had some sort of issue, but it turns out, every time I call the slot for that signal, ONLY the first time will it exec in the incorrect position in the QGraphicsScene. No matter how I manipulate the size of the Titlebar widget itself, move commands or maximize commands to the MainWindow, or even edit the splitter size for the QGraphicsView that affects the size of the QGraphicsScene, it will always be in the correct position afterwards. here is the function for execing:
void TitleBar::showContextMenu(QPoint point){
qDebug() << point;
contextMenu->exec(point);
emit _parent->focusChangedIn();
}
I printed the point at which it is calling the exec. The strangest part is that both times I right click in the same location, it will print the SAME value for the slot's positional parameter both the first exec and second exec, but be in the correct location every time other than the first. Did I forget to set some other flag when I added the context menu to the Titlebar class? Does it have anything to do with setting the QMenu's parent to the Titlebar? I'm just dumbfounded how the same QPoint could exec at two different screen locations given the same value. Does anybody have a clue what may or may not be happening on the first call to the Titlebar's slot for execing the QMenu?
EDIT: The issue stemmed from doing this line of code in the Titlebar constructor:
contextMenu = new DockItemContextMenu(this);
Changing it to:
contextMenu = new DockItemContextMenu;
fixed the issue. Does anyone know why, or is this possibly a bug? I rather not accept this as an answer because it does not explain why it happened in the first place.
Here is a minimal example with the same effect.
MainWindow.h:
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
#include <QWidget>
#include <QGraphicsView>
#include <QSplitter>
#include <QHBoxLayout>
#include <QGraphicsScene>
#include <QPointer>
#include <QTreeWidget>
#include "titlebar.h"
class MainWindow : public QMainWindow{
Q_OBJECT
public:
MainWindow(QWidget *parent = 0);
~MainWindow();
private:
};
#endif // MAINWINDOW_H
MainWindow.cpp:
#include "mainwindow.h"
MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent){
QPointer<QWidget> widgetArea = new QWidget;
QPointer<QHBoxLayout> hLayout = new QHBoxLayout;
widgetArea->setLayout(hLayout);
QPointer<QSplitter> splitter = new QSplitter;
hLayout->addWidget(splitter);
QPointer<QTreeView> tree = new QTreeView;
splitter->addWidget(tree);
QPointer<QGraphicsView> view = new QGraphicsView;
splitter->addWidget(view);
splitter->setStretchFactor(0, 1);
splitter->setStretchFactor(1, 4);
QPointer<QGraphicsScene> scene = new QGraphicsScene;
view->setScene(scene);
QPointer<Titlebar> blue = new Titlebar;
blue->setObjectName("blue");
blue->setStyleSheet(QString("#blue{background-color: rgb(0,0,255)}"));
blue->resize(250,250);
scene->addWidget(blue);
this->setCentralWidget(widgetArea);
this->resize(1000,750);
}
MainWindow::~MainWindow(){
}
Titlebar.h:
#ifndef TITLEBAR_H
#define TITLEBAR_H
#include <QMenu>
#include <QWidget>
#include <QPointer>
#include <QDebug>
#include <QMouseEvent>
class Titlebar : public QWidget{
Q_OBJECT
public:
explicit Titlebar(QWidget *parent = nullptr);
QPointer<QMenu> menu;
QPoint currentPos;
protected slots:
void mousePressEvent(QMouseEvent* event);
void mouseMoveEvent(QMouseEvent* event);
void showContextMenu(QPoint point);
};
#endif // TITLEBAR_H
Titlebar.cpp:
#include "titlebar.h"
Titlebar::Titlebar(QWidget *parent) : QWidget(parent){
setContextMenuPolicy(Qt::CustomContextMenu);
connect(this, SIGNAL(customContextMenuRequested(QPoint)), this, SLOT(showContextMenu(QPoint)), Qt::QueuedConnection);
menu = new QMenu(this);
menu->addAction("Test");
}
void Titlebar::showContextMenu(QPoint point){
qDebug() << point;
menu->exec(mapToGlobal(point));
}
void Titlebar::mouseMoveEvent(QMouseEvent *event){
if (event->buttons() && Qt::LeftButton){
QPoint diff = event->pos() - currentPos;
move(pos() + diff);
}
}
void Titlebar::mousePressEvent(QMouseEvent * event){
currentPos = event->pos();
}
main.cpp:
#include "mainwindow.h"
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
So this runs and reproduces the error accordingly. If you change the line in Titlebar.cpp from
menu = new QMenu(this);
to:
menu = new QMenu;
Then it works correctly. ONLY the first right click to open the context menu will spawn in the incorrect location on screen. All subsequent right clicks will now follow either the widget/window/splitter in any combination. I don't get it, can someone tell me if this is actually a bug or not.
You need to add one line of code because your using a QGraphicsProxyWidget which is part of a QGraphicsScene. The scene is represented by a QGraphicsView which inherits QAbstractScrollArea. This causes the context menu to be shown via the viewport and not the widget itself. Therefore adding this one line of code will override the title bar to not be embedded in the scene when it's parent was already embedded in the scene. Effectively making it reference the widget again and not the viewport.
In the MainWindow.cpp right after line 26 add
blue->setWindowFlags(Qt::BypassGraphicsProxyWidget);
I have a simple flow
Click on QPushButton
QMenu with a couple of actions appears
Navigate through the QMenu using key clicks or mouse move.
(Triggering actions from code isn't a way, it should be a clean GUI test).
QTest::keyClick(m_menu, Qt::Key::Key_Down); - doesn't seem to work for me.
Simple example:
#include "mainwindow.h"
#include <QTest>
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent)
{
m_button = new QPushButton("My Button", this);
m_button->setFixedSize(100,50);
m_menu = new QMenu("&Menu");
m_menu->addAction("&test1");
m_menu->addAction("&test2");
m_menu->addAction("&test3");
m_menu->addAction("&test4");
m_menu->addAction("&test5");
m_menu->addAction("&test6");
connect(m_button, SIGNAL (released()), this, SLOT (handleButton()));
}
void MainWindow::handleButton()
{
m_menu->exec(m_button->mapToGlobal(QPoint(20,20)));
QTest::qWait(2000);
for(int i = 0 ;i<=5;i++){
QTest::keyClick(m_menu, Qt::Key::Key_Down);
QTest::qWait(1000);
QTest::mouseMove(m_menu, QPoint(0,20));
QTest::qWait(1000);
}
}
MainWindow::~MainWindow()
{
}
Thanks to vahancho I found work around.
QMenu.exec() is executing synchronously. So, to have an opportunity to provide some input when menu is opened we should use next template:
QTimer::singleShot(0, [menu]()
{
//code that should be executed
});
menu->exec();
My task is to write an automated UI test for a software being developed. It happens so, that there are radiobuttons triggering a messagebox, which stops my automated test until I manually confirm it (pressing ENTER). The issue is that I do not know how I can call that newly summoned messagebox and then have it confirmed by QTest::keyClick(<object>, QtKey::Key_Enter); and have my automated test continue the run.
I am using QWidgets, QApplication, Q_OBJECT and QtTest.
I will provide a code similar to what I am working with:
void testui1(){
Form1* myform = new Form1();
myform->show();
QTest::mouseClick(myform->radioButton01, Qt::LeftButton, Qt::NoModifier, QPoint(), 100);
// Message box pops up and stops the operation until confirmed
QTest::mouseClick(myform->radioButton02, Qt::LeftButton, Qt::NoModifier, QPoint(), 100);
// again
...
}
How exactly can I script to confirm the message box automatically? The message box is only an [OK] type, so I don't need it to return whether I have pressed Yes or No. A QTest::keyClick(<target object>, Qt::Key_Enter) method needs to know to which object it should press enter to. I tried including myform into the object and it did not work. Googling I did not find the answer. I found the following result as not functioning for what I am looking for
QWidgetList allToplevelWidgets = QApplication::topLevelWidgets();
foreach (QWidget *w, allToplevelWidgets) {
if (w->inherits("QMessageBox")) {
QMessageBox *mb = qobject_cast<QMessageBox *>(w);
QTest::keyClick(mb, Qt::Key_Enter);
}
}
The problem is that once you've "clicked" on your radio button, which results in QMessageBox::exec being called, your code stops running until the user clicks on of the buttons.
You can simulate the user clicking a button by starting a timer before you click on the radio button.
In the callback function for the timer you can use QApplication::activeModalWidget() to obtain a pointer to the message box, and then just call close on it.
QTimer::singleShot(0, [=]()
{
QWidget* widget = QApplication::activeModalWidget();
if (widget)
widget->close();
});
If you want to press a specific key on the message box, you can use QCoreApplication::postEvent to post a key event to the message box
QTimer::singleShot(0, [=]()
{
int key = Qt::Key_Enter; // or whatever key you want
QWidget* widget = QApplication::activeModalWidget();
if (widget)
{
QKeyEvent* event = new QKeyEvent(QEvent::KeyPress, key, Qt::NoModifier);
QCoreApplication::postEvent(widget, event);
}
});
So in terms of how this ties into the sample code you gave:
void testui1()
{
Form1* myform = new Form1();
myform->show();
QTimer::singleShot(0, [=]()
{
QWidget* widget = QApplication::activeModalWidget();
if (widget)
widget->close();
else
QFAIL("no modal widget");
});
QTest::mouseClick(myform->radioButton01, Qt::LeftButton, Qt::NoModifier, QPoint(), 100);
}
A sample app putting all the above together:
#include <QApplication>
#include <QMainWindow>
#include <QHBoxLayout>
#include <QPushButton>
#include <QTimer>
#include <QMessageBox>
#include <iostream>
int main(int argc, char** argv)
{
QApplication app(argc, argv);
QMainWindow window;
QWidget widget;
window.setCentralWidget(&widget);
QHBoxLayout layout(&widget);
QPushButton btn("go");
layout.addWidget(&btn);
QObject::connect(&btn, &QPushButton::clicked, [&]()
{
QTimer::singleShot(0, [=]()
{
QWidget* widget = QApplication::activeModalWidget();
if (widget)
{
widget->close();
}
else
{
std::cout << "no active modal\n";
}
});
QMessageBox(
QMessageBox::Icon::Warning,
"Are you sure?",
"Are you sure?",
QMessageBox::Yes | QMessageBox::No,
&window).exec();
});
window.show();
return app.exec();
}
Clicking on Go will look like nothing is happening, as the QMessageBox is closed immediately.
To prove that the message box is shown and then closed you can increase the time in the call to QTimer::singleShot to a value such as 1000. Now it will show the message box for 1 second, and then it will be closed by the timer.
I have a very specific piece of code that needs to be executed instantly, no matter what else is going on in the gui, when the space bar is pressed. I have the following snippet of code in each of my keypress event filters:
else if(keyPressed == Qt::Key_Space){
emit sigHalted();
}
This works fine, unless certain widgets have focus. The ones causing me issues are:
QTableWidget
QPushButton
If I'm editing an in a QTableWidget, and I hit space bar, then it adds a space bar to the item in the QTableWidget instead of executing the code above. If I click a button with the mouse, and then hit space bar, it acts as if I clicked that same button again instead of executing the code above.
I know I can fix this behavior by subclassing the widgets and overriding their event filters, but I would prefer to avoid this, because I have a lot of buttons and tables and I would have to go through and replace all of them with the new, subclassed versions. Is there a way I can catch the space bar keypress event before it goes to the widget's default behavior?
You must use eventFilter.
Enable the event:
code:
#include <QApplication>
MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow)
{
ui->setupUi(this);
qApp->installEventFilter(this);
}
Declare the function:
code:
bool eventFilter(QObject *watched, QEvent *event);
Override the function:
code:
bool MainWindow::eventFilter(QObject *watched, QEvent *event)
{
if (event->type() == QEvent::KeyPress){
QKeyEvent *keyEvent = static_cast<QKeyEvent*>(event);
if (keyEvent->key() == Qt::Key_Escape){
//your code here
emit sigHalted();
return true;
}
else{
return false;
}
}
else
return QMainWindow::eventFilter(watched,event);
}