dialog content is not painted

[miso]

Hello,
my original problem was found in PyQt (http://stackoverflow.com/questions/15272040/event-loop-qtgui-qapp-processevents), but it's almost the same when I rewrote in into C++.

My goal is to show some dialog with label (something like "please wait" or whatever) while executing some other code in main thread. Main thread is important because of some error handlings (Qt Dialog with error message) etc later.
Note: I have 2 connects to button.clicked because in pyqt version there were different behaviour (first dialog works fine, second one without label). In C++ version both dialogs aren't repainted.
It seems Splash dialog is not repainted even if QApplication::processEvents(); is called. When I remove "delete splash;" line, it's repainted when main thread leaves MyWindow::handleButton method

Thank you for any help or suggestion.

Michal

[darenw]

What happens if you put another processEvents() after the sleep()? Or break up the 4-second delay into several shorter ones, with event processing between each?

[miso]

What happens if you put another processEvents() after the sleep()? Or break up the 4-second delay into several shorter ones, with event processing between each?

Yes, it helps a bit (second processEvents() caused to paint on canvas). But I don't want to have that in handleButton() method (there should be custom code, maybe qt-independent). So I'm thinking about QTimer and call processEvents() in some interval.
But there comes another problem - QTimer stops while handleButton() is executed.

[wysota]

Yes, it helps a bit (second processEvents() caused to paint on canvas). But I don't want to have that in handleButton() method (there should be custom code, maybe qt-independent).
Run that code in a separate thread.

[miso]

That would work (run custom code in separate thread in background) but I'd like to avoid that. This is how it worked before and I'd like to run it in main thread to avoid any deadlock/synchronisation dangerous.

What I tried is to run processEvents() loop (with some sleep) in another thread to re-paint the dialog. It runs correctly but without any visible result.

[wysota]

That would work (run custom code in separate thread in background) but I'd like to avoid that.
I'm sorry -- it's either threads or stalling the GUI thread while your custom code is running. Adding timers or whatever else that requires event processing will not help you in any way.


What I tried is to run processEvents() loop (with some sleep) in another thread to re-paint the dialog. It runs correctly but without any visible result.
Because it processes the other thread which has nothing to process.

You simply have no choice. Either you run custom code in thread other than the GUI thread or your GUI thread will not respond during the time the custom code is ran.

[miso]

I understand that. But because of QSplashScreen, I though it is somehow possible, isn't it?
And I can't use QSplashScreen from Python (I use PyQt4) because I can't override mousePressEvent (it's protected) so click will close the widget.

[wysota]

I understand that. But because of QSplashScreen, I though it is somehow possible, isn't it?
No, QSplashScreen works the same way. If you don't let it process events, it will not be updated.