Qt application won't repaint until first resize

[ComServant]

I'm talking about every widget, including QPushButtons / QToolButtons, custom widgets (with mouseTracking enabled) receiving mouse presses but not repainting, even after explicit calls to repaint() in the mousePressEvent() override. When they finally do repaint (after the first window resize, and then they behave normally after that) I can see that the previous mouse presses were received but the widgets appearances weren't updated. Breakpoints also tell me the same thing - their paintEvents weren't getting called, but their mousePressEvents were. Their mouse hovers only seem to take effect when the mouse was pressed ontop of them and is still being held down (as if mouseTracking is disabled), but their rpaintEvents still aren't being called. It really seems there's an invisible pop-up that has focus.

It's most likely not a borked Qt install, because it was working fine a week or two ago (I didn't notice exactly when it started), so it's most likely something in my large code project. I was hoping someone might've encountered a similar problem before and could provide some debugging tips.

For debugging Win32 programs, there are applications you can use to query the state of the application you are debugging. Has anyone written anything like that for Qt?

Even though these four a null:

QWidget *mouseGrabber = QWidget::mouseGrabber();
QWidget *keyboardGrabber = QWidget::keyboardGrabber();
QWidget *activePopup = qApp->activePopupWidget();
QWidget *activeModal = qApp->activeModalWidget();

QWidget *mouseGrabber = QWidget::mouseGrabber();
QWidget *keyboardGrabber = QWidget::keyboardGrabber();
QWidget *activePopup = qApp->activePopupWidget();
QWidget *activeModal = qApp->activeModalWidget();

To copy to clipboard, switch view to plain text mode 

...I'm only printing them out in response to a button being pressed (a button that doesn't redraw itself, but still reacts to the press just in a non-animated way), so it probably temporarily hides the active popup or whatever, giving me (possibly) misleading results. I'll try outputting it using a timer, to see if something is active.

[wysota]

It would be easier if you provided a minimal compilable example reproducing the problem.

[ComServant]

Knew someone was going to say that. =)
But if I could produce an example reproducing the problem, then I can fix it. My question is, how can I, in a complex project, isolate where the problem is? This step must be done before a minimal compilable can be created. Minimal compilable programs are usually for demonstrating flaws in Qt, where here I'm almost positive the flaw is in my own code.

This is partly a, "Does anyone recognize this particular problem, and can you point me at possible causes to save me dozens of hours of work?", and it's partly a question of, how do you debug large event-driven and signal-and-slot driven applications?

Normally, with single-threaded (hobbyist) videogame development, program execution is much more linear and easier for me to isolate the general area where the problem is. With widget-based applications, program flow is significantly more complex - jumping all over the place - and I don't have as much experience debugging that.

I was busy yesterday with other tasks, but today I'm starting to compare the diffs to find when (and hopefully where!) I introduced the problem. But if anyone has any advice of what to look for, or possible guesses at the cause, I'd greatly appreciate it.

[wysota]

But if I could produce an example reproducing the problem, then I can fix it.

Therefore you expect us to fix it just by knowing that "it doesn't work"?

My question is, how can I, in a complex project, isolate where the problem is?

There are two ways -- either start removing code from your non-working program until it starts working or start adding code to an empty program until it stops working.

Minimal compilable programs are usually for demonstrating flaws in Qt, where here I'm almost positive the flaw is in my own code.

No, minimal compilable examples are usually for finding flaws in your code by isolating code relevant to the issue. "Once you eliminate the impossible, whatever remains.. bla bla.. must be the truth".

Normally, with single-threaded (hobbyist) videogame development, program execution is much more linear and easier for me to isolate the general area where the problem is. With widget-based applications, program flow is significantly more complex - jumping all over the place - and I don't have as much experience debugging that.

Unless you introduced some threads yourself your program is still single-threaded. And since UI can operate only in the main thread, you can remove all your multi-threaded code and the problem will remain.

[ComServant]

I stand corrected; it is something within Qt (possibly). If I don't have Qt::FramelessWindowHint set on my main window, there isn't a problem. I can't reproduce it in a minimlistic program though - Qt::FramelessWindowHint alone isn't triggering it.

To hack around the problem, during startup I call this after an explicit call to QMainWindow's show() function:

this->setGeometry(this->geometry().adjusted(-1,-1,1,1));

this->setGeometry(this->geometry().adjusted(-1,-1,1,1));

To copy to clipboard, switch view to plain text mode 

This "fixes" my problem (hides it, more like). I'm not sure what the origin of the problem is. I don't know what part of my code, in combination with Qt::FramelessWindowHint, is triggering the behavior.

[wysota]

I really suggest you post some code. Without that there isn't much we can do. Right now I can only suggest installing an event filter on the application object and check whether paint events and other events you need are generated at all.