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?
views:
387answers:
2
+2
A:
Neither, processEvent() should be calld only when you have actual pending events to process. You may find this useful : http://stackoverflow.com/questions/1386043/how-to-make-qt-work-when-main-thread-is-busy
gregseth
2010-01-27 23:08:53
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
2010-01-28 01:05:44
@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
2010-01-28 19:27:31
+2
A:
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
2010-01-27 23:30:56
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
2010-01-28 01:30:32
Gui 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
2010-01-28 17:08:39