Derek Fountain wrote: > Gunnar Sletta wrote: >> Tom Schindl wrote: >>> QApplication#invokeLater(Runnable) >>> QApplication#invokeAndWait(Runnable) >> There is also the option of posting events to objects in the gui thread >> or using queued connections: >> http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-signalsandslots.html
> So how do I handle this? I'm in a method of a QWidget derived object > wanting to call its update() immediately, but can't because I'm > executing in the wrong thread. From the pointers given to me so far it > seems I might be able to use invokeLater() to start off a one line > method that calls the update(). Hi Derek, Doing invokeLater() is a perfectly valid option. You can do this without any problems. I just wanted to illustrate the alternative ways of doing cross-thread communication. > I might be able to "post an event into > the main thread," although I'm not sure how to do this (the docs I've > found so far are all C++ based). You call http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/core/QCoreApplication.html#postEvent(com.trolltech.qt.core.QObject,%20com.trolltech.qt.core.QEvent) and pass it a custom subclass of QEvent with an id which the receiver picks up in its reimplemented event() function. > Or possibly use this idea of Queued > Connections, maybe having the code called by my model-started thread > emit a signal that's indirectly connected to a slot that does the update. If you have a signal in your model: QSignal0 modelChanged and you connect modelChanged.connect(view, "update()"); then when you do: // update model in model thread modelChanged.emit(); update() will be called on the view in the GUI thread. This is a queued connection. Actually it is an auto connection which decides to do the operation queued at run time because the emitter and receiver are in different threads. The connect statement can be performed from any thread. > I'm not sure what to do. All those options seem to forego the idea of an > immediate update - they all want to tell the main thread to do the > update when it gets round to it. I'm not sure I want to make that > compromise - what if I really need the update to occur *now*? You can never get this, and you really don't want to. Excessive explicit direct repainting only leads to poor performance. At the very best you manage to sync your repaints to fit the framerate of the display in which case you have the same result as doing an update() except your own thread was blocked in the meanwhile. At the worst case your repainting more often than you have refreshrate and you're wasting cpu cycles. AWT allows this, at the cost of doing locking of the display surface, which is very costly and blocks the AWT thread from repainting (not good). You also get nice flickering and stuff. We do allow direct repaints() in Qt once you are on the main-thread which doesn't suffer from the locking issues AWT has, but its only called when its really-really needed. You are better of doing update(). best regards, Gunnar _______________________________________________ Qt-jambi-interest mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
