I have a method which is called from both QThreads
and the main thread. this method can sometimes take a long time to do its computations in a loop so I put QCoreApplication::processEvents()
and this prevents the GUI from freezing. At some point I had changed QCoreApplication::processEvents()
for QApplication::processEvents()
but that caused the GUI to freeze (im pretty sure thats what was fereezing it because since I put QCoreApplication::processEvents()
back it hasnt frozen again) Am I right to think that calling QApplication::processEvents()
from both the main thread and QThreads can freeze the GUI?
Asked
Active
Viewed 4.4k times
13

Ilya
- 4,583
- 4
- 26
- 51

yan bellavance
- 4,710
- 20
- 62
- 93
2 Answers
12
Neither, processEvent() should be calld only when you have actual pending events to process. You may find this useful : How to make Qt work when main thread is busy?
-
I am going to try QtConcurrent::run. Can I do GUI operations in there or should I still emit signals like for the case of a QThread – yan bellavance Jan 28 '10 at 01:05
-
1@yan bellavance: You should emit signals, as it will be in a separate thread. Or you could use the QFuture stuff to help, which will do a lot of creating and emitting the signals for you. – Caleb Huitt - cjhuitt Jan 28 '10 at 19:27
12
You'll be much better off moving the long-running process out of the main thread so you don't need to call processEvents()
. Within that long-running process, you can emit whatever signals you need so the gui has sufficient information to do updates, etc. processEvents
, however, is usually a crutch for a poor design.

Kaleb Pederson
- 45,767
- 19
- 102
- 147
-
I am going to try QtConcurrent::run. Can I do GUI operations in there or should I still emit signals like for the case of a QThread – yan bellavance Jan 28 '10 at 01:30
-
1Gui operations may only be performed in the main thread. QtConcurrent is a good idea, especially if you can divide your work up to utilize multiple cores. – Kaleb Pederson Jan 28 '10 at 17:08