Key press (arrow keys) cause loss of focus

[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