I added a progress bar in the GUI window, I want to create a thread, in this thread can control the position of the progress bar GUI window properti
-
In GUI window create a thread and a progress bar then connect your thread object with a "setValue slot":http://qt-project.org/doc/qt-5/qprogressbar.html#value-propof of QProgressBar in GUI window.
In the thread emit a signal to update QProgressBar.
-
I guess this should work. A bit more info on the background:
There are queued and non-queued signal-slot connections in Qt. Furthermore each QObject has a QThread it belongs to. When sender and receiver of a signal-slot connection belong to different QThreads the connection has to be queued to ensure thread-safty.
When calling "QObject::connect":http://qt-project.org/doc/qt-4.8/qobject.html#connect-3 a connection where sender and receiver belong to different QThreads is established as a queued connection by default (see "Qt:ConnectionType":http://qt-project.org/doc/qt-4.8/qt.html#ConnectionType-enum). I never tried to establish a connection where one of the parts (sender/receiver) is actually a QThread, but I guess a QThread should "belong to itself", shouldn't it?
Hope it helps.
Soraltan
-
Ok, maybe I was wrong. Maybe a QThread belongs to the main thread and not to the thread it represents. I didn't find section in the docu really stating that, but "Qt Doc":http://qt-project.org/doc/qt-4.8/threads-qobject.html states:
bq. The child of a QObject must always be created in the thread where the parent was created. This implies, among other things, that you should never pass the QThread object (this) as the parent of an object created in the thread (since the QThread object itself was created in another thread).
So QThread would require you to make this connection queued manually (as the default in this case would be a non-queued connection).
@
connect(pointer_to_thread,
SIGNAL(signal_for_new_progress(int)),
pointer_to_bar,
SLOT(setValue(int)),
Qt::QueuedConnection)
@Anyhow, the better way would probably be to have a QObject (not QThread) which emits the signal_for_new_progress (as I called it). You could "move":http://qt-project.org/doc/qt-4.8/qobject.html#moveToThread this to the QThread and make a normal connect (which would then default to a queued connection).
The general idea for threading in Qt is to not overwrite the run method (as you would usually do). Creating a QThread and calling start() starts a brand new Qt Event Loop within that thread. You then move QObjects which do your work to the QThread and trigger their actions via (Queued) signal-slot connections. See at "Threads and QObjects":http://qt-project.org/doc/qt-4.8/threads-qobject.html for more info.
I personally really like this approach. Threading is always kind of error prone (except maybe for experienced thread-users) and threading-errors are hard to debug. The Qt threading approach avoids a bunch of typical threading pitfalls.
Best
Soraltan
