QT Widgets not responding to touch event sometimes
-
Re: QT Widgets not responding to touch event sometimes
I'm in the same situation.
Qt 5.12.12
Qt Widget application
・I use QtInputMethod_GooglePinyin under linux,sometimes the touch on the virtual keyboard can't work , especially after other dialog pop up and close.
・When in this situation, USB-mouse can work.( in other word, I can click the button on the virtual keyboard with USB-mouse,but can't touch to generate the clicked signal)
・And If I use USB-mouse click or touch some other edit places(the virtual keyboard hide at the same time),When I activate the virtual keyboard again, it can respond to touch event normally.
https://github.com/tgtsml/QtInputMethod_GooglePinyin
-
-
Hi everyone,
we are having a similar problem with a standard Qt 5.15.2 widgets application (no QML) on 32 bit x86 linux. Our user interface consists of a number of classes derived from QMainWindow which are displayed with show(); we have touch screens from ILITEK which generates touch events (TouchBegin, TouchEnd, TouchMove) that are then translated into Mouse events by Qt :qt.events Type=TouchBegin, objectName=ScreenTemplateWindow, isButton=false qt.events Type=TouchBegin, objectName=, isButton=true qt.events Type=MouseButtonPress, objectName=ScreenTemplateWindow, isButton=false, [xPos=867, yPos=752, source=MouseEventSynthesizedByQt] qt.events Type=MouseButtonPress, objectName=, isButton=true, [xPos=867, yPos=752, source=MouseEventSynthesizedByQt] qt.events Type=TouchUpdate, objectName=ScreenTemplateWindow, isButton=false
After a while, this just randomly stops. The Touch events are still reported, but no new Mouse events are generated, and thus nothing can be clicked anymore. Using a real mouse (or a keyboard with touchpad) which generates these Mouse events itself still works, though.
qt.events Type=TouchBegin, objectName=ScreenTemplateWindow, isButton=false qt.events Type=TouchBegin, objectName=, isButton=true qt.events Type=TouchEnd, objectName=ScreenTemplateWindow, isButton=false
What can cause this behaviour? I don't think it's directly related to the exec() issue listed in the bug report, because while we are using QDialogs and call exec() from time to time, nothing like that happens in the vicinity of these errors, at the time, we are only creating and destroying QMainWindow derivates.
Any help is appreaciated.
Cheers, Michael.
-
Qt does have some issues on touch screen. I simply handled this problem as follows in event filter.
if ( QEvent::MouseButtonPress == event->type() || QEvent::TouchBegin == event->type() ) {
handle button press event
}in order to make the code working for mouse click as well, the button clicked with mouse can be marked with enter event in advance.
-
-
@MicHes My Qt version is 5.15.2 as well. Add event filter to your QMainWindow(I have a QDialog). Then you can catch all events
and simply take touch and mouse events out to handle. You can print out all events to see what is going on when you touch the screen or press mouse. All types are here: https://doc.qt.io/qt-5/qevent.html -
Hi @JoeCFD,
that is exactly what we are already doing (1); the log lines quoted above are from an event filter routine. We only know because of this very event filter that the touch events are no longer synthesized into mouse events .What we still don't know is:
- why this is happening, and
- how we can change that behaviour in any way, shape or form so that we get Button press events consistently.
Our UI mostly consists of QPushButtons, and if they don't get pressed anymore, the application becomes pretty much useless.
I hope this clears things up.
Cheers, Michael.
(1) = To be precise, we have overloaded the notify() call of the QApplication class as follows:
bool Application::notify(QObject *receiver, QEvent *event) { switch (event->type()) { case QEvent::MouseButtonPress: case QEvent::MouseButtonRelease: case QEvent::MouseButtonDblClick: // case QEvent::MouseMove: handleMouseEvent(receiver, event); break; case QEvent::HoverEnter: case QEvent::HoverLeave: case QEvent::HoverMove: handleHoverEvent(receiver, event); break; case QEvent::GraphicsSceneMouseMove: case QEvent::GraphicsSceneMousePress: case QEvent::GraphicsSceneMouseRelease: case QEvent::GraphicsSceneMouseDoubleClick: case QEvent::GraphicsSceneHoverEnter: case QEvent::GraphicsSceneHoverMove: case QEvent::GraphicsSceneHoverLeave: handleGraphicsSceneEvent(receiver, event); break; case QEvent::NonClientAreaMouseMove: case QEvent::NonClientAreaMouseButtonPress: case QEvent::NonClientAreaMouseButtonRelease: handleNonClientEvent(receiver, event); break; case QEvent::TabletMove: case QEvent::TabletPress: case QEvent::TabletRelease: handletTableEvent(receiver, event); break; case QEvent::TouchBegin: case QEvent::TouchUpdate: case QEvent::TouchEnd: case QEvent::TouchCancel: handleTouchEvent(receiver, event); break; case QEvent::GrabMouse: case QEvent::UngrabMouse: handleGrabEvent(receiver, event); break; } return QApplication::notify(receiver, event); }
The handleXYZ() routines do straightforward logging, here's two examples:
void Application::handleTouchEvent(QObject *receiver, QEvent *event) { QAbstractButton* pushButton = qobject_cast<QAbstractButton*>(receiver); logger->log(DEBUG, QString("Type=%1, objectName=%2, isButton=%3") .arg(typeToString(event)) .arg(receiver->objectName()) .arg(pushButton != nullptr ? "true" : "false")); } void Application::handleMouseEvent(QObject *receiver, QEvent *event) { QMouseEvent* mouseEvent = dynamic_cast<QMouseEvent*>(event); QAbstractButton* pushButton = qobject_cast<QAbstractButton*>(receiver); QString moreText; if (mouseEvent != nullptr) { QString eventSource = "?"; switch (mouseEvent->source()) { case 0: eventSource = "MouseEventNotSynthesized"; break; case 1: eventSource = "MouseEventSynthesizedBySystem"; break; case 2: eventSource = "MouseEventSynthesizedByQt"; break; case 3: eventSource = "MouseEventSynthesizedByApplication"; break; } moreText = QString("xPos=%1, yPos=%2, source=%3") .arg(mouseEvent->globalX()) .arg(mouseEvent->globalY()) .arg(eventSource); } logger->log(DEBUG,QString("Type=%1, objectName=%2, isButton=%3, [%4]") .arg(typeToString(event)) .arg(receiver->objectName()) .arg(pushButton != nullptr ? "true" : "false") .arg(moreText)); }
-
I do not know the reasons and also did not spend time to debug into the Qt code for the check. There could be reasons like: drivers, Qt bugs, etc. I have only one dialog for exit option with 4 buttons. The following code(plus marking the button with enter event) works fine for this purpose.
if ( QEvent::MouseButtonPress == event->type() || QEvent::TouchBegin == event->type() ) { handle button press event return true; } return QDialog::eventFilter(obj, event);
-
bool ExitDialog::eventFilter( QObject *obj, QEvent *event) { if ( QEvent::Enter == event->type() && this != obj ) { ui->selectedButton = dynamic_cast< QPushButton * >( obj ); } if ( QEvent::Leave == event->type() && this != obj ) { ui->selectedButton = nullptr; } if ( QEvent::MouseButtonPress == event->type() || QEvent::TouchBegin == event->type() ) { bool ok{ false }; if ( obj == ui->exitButton || ui->selectedButton == ui->exitButton ) { handle exit button press event ok = true; } return ok; } return QDialog::eventFilter(obj, event); }
-
Hi @JoeCFD ,
this is just for one specific button (ui->exitButton), right?and where you write
handle exit button press event
I should generate a ButtonPressed event for my widget?
I'm not sure how to scale this properly; I have about 15 QMainWindows with north of 150 QPushButtons in total, and simply cannot manually add handling code for each and every one of them, because that's not maintainable.
Cheers, Michael.
-
Hi @JoeCFD,
speed is not the main issue here - I meant that code you need to change every time you add or remove a button would not be maintainable. There would need to be an routine that automatically finds the button (if any) a touch event belongs to, otherwise it will cause more problems down the line.Greetings, Michael.
-
-
@MicHes said in QT Widgets not responding to touch event sometimes:
Hi @JoeCFD,
speed is not the main issue here - I meant that code you need to change every time you add or remove a button would not be maintainable. There would need to be an routine that automatically finds the button (if any) a touch event belongs to, otherwise it will cause more problems down the line.Greetings, Michael.
or use static cast for find button name and apply code for that when find it.