Key press (arrow keys) cause loss of focus

[Axel Spoerl]

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(); 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.

Cheers
Axel

[Perdrix]

@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]

@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

[Perdrix]

@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]

@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 be nullptr, 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.

[Perdrix]

@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]

@Perdrix
That baffles me. Can you step into Qt code?
Or isolate the issue in a minimal reproducer?

[Perdrix]

@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

[Axel Spoerl]

@Perdrix
If you can compile Qt, throw a qDebug() << __FUNCTION__ << typeinto the c'tor of QFocusEvent (qevent.cpp:1562).
Set a break point there and continue, unless it's a QEvent::FocusOut. If it's the FocusOut, that eventually steals focus, the call stack will tell who it is.

[Perdrix]

@Axel-Spoerl :

The reason in the focus event is 3 (Qt::ActiveWindowFocusReason).

This was invoked indirectly from line 1940 in QApplicationPrivate::notifyActiveWindowChange()

David

[Axel Spoerl]

@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 *focus argument pointing to?
Shouldn't be nullptr with ActiveWindowFocusReason...

[Perdrix]

@Axel-Spoerl It's pointing to a QScrollArea object (which could be the scroll area in the other dock widget)

[Axel Spoerl]

@Perdrix
Getting more and more interesting.
Could you assign a QObject::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.

[Perdrix]

@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.

[Perdrix]

@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.

[Axel Spoerl]

@Perdrix
Hi David,
glad that the issue is resolved!
Thanks for letting me know - was a pleasure.
Cheers
Axel