Key press (arrow keys) cause loss of focus
-
@Axel-Spoerl For further information this is what the code I use does as the image starts to load and on completion. All the controls referenced here are in the "central widget" the main window, not the dock widget.
Starting to load:
// // Display the "Loading filename" with red background gradient while loading in background // ui->information->setStyleSheet( "QLabel { background: qlineargradient(spread:pad, x1:0, y1:0, x2:1, y2:0," "stop:0 rgba(252, 251, 222, 0), stop:1 rgba(255, 151, 154, 255)) }"); ui->information->setText(tr("Loading %1", "IDS_LOADPICTURE") .arg(fileName)); // // No longer interested in signals from the imageView object // ui->picture->disconnect(editStars, nullptr); ui->picture->disconnect(selectRect, nullptr); pToolBar->setVisible(false); pToolBar->setEnabled(false); editStars->setBitmap(nullptr);When the image completes loading:
// // The image we want is available in the cache // m_LoadedImage.m_Image = pImage; m_LoadedImage.m_pBitmap = pBitmap; if (m_GammaTransformation.isInitialized()) ApplyGammaTransformation(m_LoadedImage.m_Image.get(), m_LoadedImage.m_pBitmap.get(), m_GammaTransformation); ui->picture->setPixmap(QPixmap::fromImage(*(m_LoadedImage.m_Image))); if (frameList.isLightFrame(fileToShow)) { editStars->setLightFrame(fileName); editStars->setBitmap(pBitmap); if (pToolBar->rectAction->isChecked()) { editStars->rectButtonPressed(); selectRect->rectButtonPressed(); } else if (pToolBar->starsAction->isChecked()) { editStars->starsButtonPressed(); selectRect->starsButtonPressed(); } else if (pToolBar->cometAction->isChecked()) { editStars->cometButtonPressed(); selectRect->cometButtonPressed(); } pToolBar->setVisible(true); pToolBar->setEnabled(true); } else { pToolBar->setVisible(false); pToolBar->setEnabled(false); editStars->setBitmap(nullptr); }; CBilinearParameters Transformation; VOTINGPAIRVECTOR vVotedPairs; if (frameList.getTransformation(fileName, Transformation, vVotedPairs)) editStars->setTransformation(Transformation, vVotedPairs); ui->information->setStyleSheet( "QLabel { background: qlineargradient(spread:pad, x1:0, y1:0, x2:1, y2:0," "stop:0 rgba(138, 185, 242, 0), stop:1 rgba(138, 185, 242, 255)) }"); ui->information->setText(fileName);The loss of focus on the table view happens just after the code for completion of loading is finished (IOW the table view retains focus and selection until just after loading has finished).
Hi @Perdrix,
happy Christmas to you to and all the best for upcoming 2024!Sorry for asking the dock widget stuff. My initial thought was that you are suffering from a long standing bug, where a manually undocked dock widget may end up wrapped in an invisible
QDockWidgetGroupWindow. Besides crashing when hovered over another floating dock, it is well known for mangling the focus chain. But that doesn't seem to be the case here. Just btw, this (and a whole bunch of other fixes) make dock widgets pretty stable from 6.5 onward.I can't figure anything fishy in the code.
I downloaded and inspected the Excel file. Thanks for the explanations thereof. However, it doesn't seem to contain
qDebug() << QApplication::focusWidget();andqDebug() << targetWidget::focusWidget(). Would be great if you could add those into the diagnostic output. The former will tell us, when the table view has lost focus. The latter will tell us, if a focus or a broken chain has gotten in our way.Cheers
AxelSoftware Engineer
The Qt Company, Oslo -
Hi @Perdrix,
happy Christmas to you to and all the best for upcoming 2024!Sorry for asking the dock widget stuff. My initial thought was that you are suffering from a long standing bug, where a manually undocked dock widget may end up wrapped in an invisible
QDockWidgetGroupWindow. Besides crashing when hovered over another floating dock, it is well known for mangling the focus chain. But that doesn't seem to be the case here. Just btw, this (and a whole bunch of other fixes) make dock widgets pretty stable from 6.5 onward.I can't figure anything fishy in the code.
I downloaded and inspected the Excel file. Thanks for the explanations thereof. However, it doesn't seem to contain
qDebug() << QApplication::focusWidget();andqDebug() << targetWidget::focusWidget(). Would be great if you could add those into the diagnostic output. The former will tell us, when the table view has lost focus. The latter will tell us, if a focus or a broken chain has gotten in our way.Cheers
Axel@Axel-Spoerl said in Key press (arrow keys) cause loss of focus:
I downloaded and inspected the Excel file. Thanks for the explanations thereof. However, it doesn't seem to contain qDebug() << QApplication::focusWidget(); and qDebug() << targetWidget::focusWidget(). Would be great if you could add those into the diagnostic output. The former will tell us, when the table view has lost focus. The latter will tell us, if a focus or a broken chain has gotten in our way.
I'm puzzled too , the focus change events all have a details section containing the reason for the focus change, then the class name QApplication::focusWidget() and then class name of myTableView->focusWidget():
e.g.: Window System;QScrollArea 0;QTableView 0
I've modified the code to use a QDebug object to display the object pointer returned by focusWidget() calls.
The updated xls file is here:
www.perdrix.co.uk/DSSEvents%202023-12-28T15-41-51.xlsx
David
-
@Axel-Spoerl said in Key press (arrow keys) cause loss of focus:
I downloaded and inspected the Excel file. Thanks for the explanations thereof. However, it doesn't seem to contain qDebug() << QApplication::focusWidget(); and qDebug() << targetWidget::focusWidget(). Would be great if you could add those into the diagnostic output. The former will tell us, when the table view has lost focus. The latter will tell us, if a focus or a broken chain has gotten in our way.
I'm puzzled too , the focus change events all have a details section containing the reason for the focus change, then the class name QApplication::focusWidget() and then class name of myTableView->focusWidget():
e.g.: Window System;QScrollArea 0;QTableView 0
I've modified the code to use a QDebug object to display the object pointer returned by focusWidget() calls.
The updated xls file is here:
www.perdrix.co.uk/DSSEvents%202023-12-28T15-41-51.xlsx
David
@Perdrix
Hi David,hm, that looks like the table view consumes a straight forward
QEvent::FocusOut. That must originate from somewhere.
To figure that out, I'd set a break point on the focus out event handler and look at the call stack. Someone is stealing focus here. Much grief is caused by focus thieves.Cheers
AxelSoftware Engineer
The Qt Company, Oslo -
@Perdrix
Hi David,hm, that looks like the table view consumes a straight forward
QEvent::FocusOut. That must originate from somewhere.
To figure that out, I'd set a break point on the focus out event handler and look at the call stack. Someone is stealing focus here. Much grief is caused by focus thieves.Cheers
Axel@Axel-Spoerl QT version 6.6.1: Here's the call stack at the time the event filter receives that FocusOut event:
It's not at all clear to me why it is doing that.
If there's information you need me to dig out from that call stack please let me know.
David
-
@Axel-Spoerl QT version 6.6.1: Here's the call stack at the time the event filter receives that FocusOut event:
It's not at all clear to me why it is doing that.
If there's information you need me to dig out from that call stack please let me know.
David
@Perdrix
Hi David,the gui event dispatcher sends posted events, which makes it forward window system events. The first of those causes a focus change. It doesn't result from the application's main thread, because we don't see any
postEvent()in the call stack. AFAIK, that can have two possible reasons:- The window manager decides, that another application gets focus. It can be anything from the debugger to a system popup or a logging window receiving output to display.
- The focus widget disappears (it gets hidden or destroyed) and the focus chain is broken, which is why the next focus widget can't be established.
It would be helpful to know the values of
QWidget * focus, Qt::FocusReason reasonin Line 1539 - 6 lines down from the break point. The widget will probably benullptr, because that's where we end up. The focus reason will not tell us what exactly is going on, but it will tell us why the focus was changed.Software Engineer
The Qt Company, Oslo -
@Perdrix
Hi David,the gui event dispatcher sends posted events, which makes it forward window system events. The first of those causes a focus change. It doesn't result from the application's main thread, because we don't see any
postEvent()in the call stack. AFAIK, that can have two possible reasons:- The window manager decides, that another application gets focus. It can be anything from the debugger to a system popup or a logging window receiving output to display.
- The focus widget disappears (it gets hidden or destroyed) and the focus chain is broken, which is why the next focus widget can't be established.
It would be helpful to know the values of
QWidget * focus, Qt::FocusReason reasonin Line 1539 - 6 lines down from the break point. The widget will probably benullptr, because that's where we end up. The focus reason will not tell us what exactly is going on, but it will tell us why the focus was changed.@Axel-Spoerl I put this in my Event Logging code:
case QEvent::FocusOut: inputType = FOCUS; eventType = "FocusOut"; if (tableView == obj) __debugbreak(); break;When the breakpoint is hit I think the relevant part of the call stack is:
where the focus change is being driven from QGuiApplicationPrivate::processActivatedEvent() at line 2562. At that point in the code, newFocus is a null pointer and previousFocusObject -> my table view object.
So why is the code forcing a focus change?
David
-
@Axel-Spoerl I put this in my Event Logging code:
case QEvent::FocusOut: inputType = FOCUS; eventType = "FocusOut"; if (tableView == obj) __debugbreak(); break;When the breakpoint is hit I think the relevant part of the call stack is:
where the focus change is being driven from QGuiApplicationPrivate::processActivatedEvent() at line 2562. At that point in the code, newFocus is a null pointer and previousFocusObject -> my table view object.
So why is the code forcing a focus change?
David
@Perdrix
That baffles me. Can you step into Qt code?
Or isolate the issue in a minimal reproducer?Software Engineer
The Qt Company, Oslo -
@Perdrix
That baffles me. Can you step into Qt code?
Or isolate the issue in a minimal reproducer? -
@Axel-Spoerl I can step into and put breakpoints into the Qt code.
Please tell me where you want the breakpoints and what information you need
@Perdrix
If you can compile Qt, throw aqDebug() << __FUNCTION__ << typeinto the c'tor ofQFocusEvent(qevent.cpp:1562).
Set a break point there and continue, unless it's aQEvent::FocusOut. If it's theFocusOut, that eventually steals focus, the call stack will tell who it is.Software Engineer
The Qt Company, Oslo -
@Perdrix
If you can compile Qt, throw aqDebug() << __FUNCTION__ << typeinto the c'tor ofQFocusEvent(qevent.cpp:1562).
Set a break point there and continue, unless it's aQEvent::FocusOut. If it's theFocusOut, that eventually steals focus, the call stack will tell who it is. -
The reason in the focus event is 3 (Qt::ActiveWindowFocusReason).
This was invoked indirectly from line 1940 in QApplicationPrivate::notifyActiveWindowChange()
David
@Perdrix said in Key press (arrow keys) cause loss of focus:
The reason in the focus event is 3 (Qt::ActiveWindowFocusReason).
That's interesting. What's the
QWidget *focusargument pointing to?
Shouldn't be nullptr withActiveWindowFocusReason...Software Engineer
The Qt Company, Oslo -
@Perdrix said in Key press (arrow keys) cause loss of focus:
The reason in the focus event is 3 (Qt::ActiveWindowFocusReason).
That's interesting. What's the
QWidget *focusargument pointing to?
Shouldn't be nullptr withActiveWindowFocusReason... -
@Axel-Spoerl It's pointing to a QScrollArea object (which could be the scroll area in the other dock widget)
@Perdrix
Getting more and more interesting.
Could you assign aQObject::objectName()to the suspicious scroll area? That will become visible in the debugger, so you can easily identify which one it is. Looks like the arrow key event gets delivered to another dock widget, which then consumes the event in an attempt to scroll. Eventually it gets focus as a stray bullet.Software Engineer
The Qt Company, Oslo -
@Perdrix
Getting more and more interesting.
Could you assign aQObject::objectName()to the suspicious scroll area? That will become visible in the debugger, so you can easily identify which one it is. Looks like the arrow key event gets delivered to another dock widget, which then consumes the event in an attempt to scroll. Eventually it gets focus as a stray bullet.@Axel-Spoerl The variable focusWidget set at line 1937 in QApplicationPrivate::notifyActiveWindowChange() points to the QMainWindow derived class for the application. The code then calls setActiveWindow() for that.
By the time this all gets to the actual Event Filter code the object to which focus is being given is the scroll area that belongs to the "other" dock widget.
I can recreate the problem without use of arrow keys - just clicking on a row in the table view selects it and starts the loading of the image. Just after the loading of the image completes, the focus is lost. The code that executes in my application on completion of loading the image was posted earlier in this thread.
-
@Axel-Spoerl The variable focusWidget set at line 1937 in QApplicationPrivate::notifyActiveWindowChange() points to the QMainWindow derived class for the application. The code then calls setActiveWindow() for that.
By the time this all gets to the actual Event Filter code the object to which focus is being given is the scroll area that belongs to the "other" dock widget.
I can recreate the problem without use of arrow keys - just clicking on a row in the table view selects it and starts the loading of the image. Just after the loading of the image completes, the focus is lost. The code that executes in my application on completion of loading the image was posted earlier in this thread.
@Axel-Spoerl I found the problem!!!
The code that was called on completion of loading of the image contained the following:
if (pToolBar->rectAction->isChecked()) { editStars->rectButtonPressed(); selectRect->rectButtonPressed(); } else if (pToolBar->starsAction->isChecked()) { editStars->starsButtonPressed(); selectRect->starsButtonPressed(); } else if (pToolBar->cometAction->isChecked()) { editStars->cometButtonPressed(); selectRect->cometButtonPressed(); }each of the xxxxButtonPressed() member functions called activateWindow(); which in the end resulted in the table view losing focus. I removed the activateWindow(); calls and now it works as it should.
Thank you so much for your help - without it I would probably still be struggling with this for many weeks to come.
-
P Perdrix has marked this topic as solved on
-
@Axel-Spoerl I found the problem!!!
The code that was called on completion of loading of the image contained the following:
if (pToolBar->rectAction->isChecked()) { editStars->rectButtonPressed(); selectRect->rectButtonPressed(); } else if (pToolBar->starsAction->isChecked()) { editStars->starsButtonPressed(); selectRect->starsButtonPressed(); } else if (pToolBar->cometAction->isChecked()) { editStars->cometButtonPressed(); selectRect->cometButtonPressed(); }each of the xxxxButtonPressed() member functions called activateWindow(); which in the end resulted in the table view losing focus. I removed the activateWindow(); calls and now it works as it should.
Thank you so much for your help - without it I would probably still be struggling with this for many weeks to come.
@Perdrix
Hi David,
glad that the issue is resolved!
Thanks for letting me know - was a pleasure.
Cheers
Axel
