Key press (arrow keys) cause loss of focus

[Perdrix]

I have a table view in a dock widget.

If I use the up and down arrow keys on the keyboard when the dock widget is docked the focus line in the table view changes as expected with no side effects.

When the dock widget is undocked, then the table view (or the dock widget) loses keyboard focus.

What do I need to do so this doesn't happen?

Thanks
David

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

[mpergand]

@Perdrix
I would say the table has no focus anymore;
you may need to click on it or set the focus widget explicitly by code with:
tableview->setFocus();

[Perdrix]

@mpergand I get that, but WHY is it losing focus? The only difference is that the dock widget is undocked.

Here's a log of events at the time:

time	input type	event type	target widget class	details
23696	Keyboard	KeyRelease	QWidgetWindow 2	16777237;;
23696	Keyboard	KeyRelease	QTabBar 0	16777237;;
23696	Keyboard	KeyRelease	QWidget 4	16777237;;
23696	Keyboard	KeyRelease	DSS::PictureList 0	16777237;;
23713	Keyboard	KeyRelease	QWidgetWindow 2	16777237;;
23713	Keyboard	KeyRelease	QTabBar 0	16777237;;
23713	Keyboard	KeyRelease	QWidget 4	16777237;;
23713	Keyboard	KeyRelease	DSS::PictureList 0	16777237;;

And in any case where would I put that setFocus()??? I don't handle keyEvents for the tableView

[mpergand]

@Perdrix
Does the dock the active window.
Does an other widget in the dock have the focus.

[Perdrix]

@mpergand The table view in the dock window HAD focus at the start. I'm not sure what has focus at the end.

[jeremy_k]

@Perdrix said in Key press (arrow keys) cause loss of focus:

@mpergand The table view in the dock window HAD focus at the start. I'm not sure what has focus at the end.

Use QApplication::focusChanged(QWidget *old, QWidget *now), or filter the application for focus events.

[ChrisW67]

@Perdrix said in Key press (arrow keys) cause loss of focus:

I get that, but WHY is it losing focus? The only difference is that the dock widget is undocked.

How did the dock widget get undocked? The result of human action or was it instigated by code? The former should be expected to take focus.

[Perdrix]

@jeremy_k Hmm I'm now logging focus events, but I'm unclear how to interpret this:

The class DSS::PictureList is multiply inherited from QDockWidget and Ui::PictureList which contains a QTableView and a QTabBar.

class Ui_PictureList
{
public:
    QWidget *dockWidgetContents;
    QVBoxLayout *verticalLayout;
    QTableView *tableView;
    QTabBar *tabBar;

[Perdrix]

Further information: Here's what the event log looks like when the dock widget is docked (and focus is not lost):

D.

[Perdrix]

@ChrisW67 Manually undocked

[Perdrix]

I changed my code so that the table view is no longer disabled as the image is loaded. Unfortunately the focus on the table view is still lost as is the "selected item" highlighting.

Here's what I believe to be the critical part from my event log.

At time 22469 I clicked on a row of the table view which made that the current selected row. This triggered my code that loads an image. This updated the text in a QLabel in the main client area of the main window and then started the thread to load the image.

At time 28390, the thread completed its work and drove the code that updated the QLabel again to show the image loading was complete. At this point the weird stuff happened which is the sequence of FocusOut and FocusIn events that takes focus away from the table view.

If I run the application with the dock window (that contains the table view) docked, this is the behaviour I see.

Which is what I would hope and expect to see - the table view doesn't loose focus in this case...

What on earth is causing this - I have now removed all code that I believe might have interfered ...

[Axel Spoerl]

@Perdrix
Do I understand this right, your colums are

• time
• event class
• event type
• class of the event receiver
• (don't understand what the last column is).

What looks odd at first glance, is QFusionStyle consuming QEvent::FocusIn.
OTOH the table view seems to get the focus event, but for some reason it's propagated to the fusion style immediately.

To isolate the problem:

• which Qt version are we talking about?
• on which OS is this happening?
• is it OS specific at all?
• could you please add the output of QApplication::focusWidget() and yourTableView->focusWidget() to each line of the debugging output?
• how exactly is the dock widget being undocked? setFloating(true), or dragged out of the main dock? If the latter: Was it tabbed or not?
• what happens, if you hover the undocked dock widget (the one containing the table view) over another floating dock widget?

[Perdrix]

@Axel-Spoerl Hi Axel, Happy Christmas to you.

This is Qt 6.6.1, but also happens on 6.5.1

The last column (details column) contains interesting stuff to do with the event:

e.g. for a Focus Event it is filled as follows:

        switch (focusEvent->reason())
        {
        case Qt::MouseFocusReason:
            details += "Mouse action";
            break;
        case Qt::TabFocusReason:
            details += "Tab pressed";
            break;
        case Qt::BacktabFocusReason:
            details += "Backtab pressed";
            break;
        case Qt::ActiveWindowFocusReason:
            details += "Window System";
            break;
        case Qt::PopupFocusReason:
            details += "Popup";
            break;
        case Qt::ShortcutFocusReason:
            details += "Buddy shortcut";
            break;
        case Qt::MenuBarFocusReason:
            details += "Menu bar";
            break;
        case Qt::OtherFocusReason:
            details += "Other";
            break;
        }

This is all on Windows (11). I've not yet finished making the code portable.

I added this after the switch statement shown above:

       //
               // Add the value of QApplication::focusWidget()
               //
               QObject* object{ nullptr };
               object = QApplication::focusWidget();
               if (nullptr != object)
               {
                   className = object->metaObject()->className();
                   if (!this->widgetPointerToID.contains(className) || !this->widgetPointerToID[className].contains(object))
                   {
                       this->widgetPointerToID[className][object] = this->widgetPointerToID[className].size();
                   }
                   id = this->widgetPointerToID[className][object];
                   className += " " + QString::number(id);
                   details += ";" + className;
               }
               else details += ";nullptr";
        
               //
               // Add the value of tableView->focusWidget
               //
               object = this->tableView->focusWidget();
               if (nullptr != object)
               {
                   className = object->metaObject()->className();
                   if (!this->widgetPointerToID.contains(className) || !this->widgetPointerToID[className].contains(object))
                   {
                       this->widgetPointerToID[className][object] = this->widgetPointerToID[className].size();
                   }
                   id = this->widgetPointerToID[className][object];
                   className += " " + QString::number(id);
                   details += ";" + className;
               }
               else details += ";nullptr";        

The dock window was manually undocked by double-clicking its title bar. It isn't a tabbed dock widget.

Nothing much happens when I move that undocked dock widget over another undocked dock widget it just sits above it in Z-Order.

And finally we get the linked file (below) converted from a csv to an xls file.

http://www.perdrix.co.uk/DSSEvents%202023-12-26T16-56-55.xls

[Perdrix]

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

[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