QThread with signals and slots

Satmosc

[quote author="Andre" date="1306745564"]Copy/paste from the mentioned wiki entry:

@
class Worker : public QObject
{
Q_OBJECT

public slots:
void doWork() {
/* ... */
}
};

/* ... */
QThread *thread = new QThread;
Worker *worker = new Worker;
connect(obj, SIGNAL(workReady()), worker, SLOT(doWork()));
worker->moveToThread(thread);
thread->start();
@
[/quote]

Thank you very much. so , it means SubClassing is already over since Qt 4.4(which it is not a Abstract class anymore) . so , I should use thread always this way !?
by the way , the Qt wiki looks excelent .

@peppe : in that example from Qt Sources I see that the thread::Start has been called from thread subclass and not the thread that object lives in.

andre

It is not impossible to subclass QThread and use it that way, but it is no longer the recommended way to do things. I won't say you should always use the create-a-worker-QObject-and-move-it-to-a-vanilla-QThread method, but in general, yes, that is the way to go. Especially if you plan to start using signals and slots.

Satmosc

@Andre: Thanks for information. yes , I guess there are situation that we may need to create new class from Qthread to add or reimplement functions.

dangelog

[quote author="Satmosc" date="1306746483"]
@peppe : in that example from Qt Sources I see that the thread::Start has been called from thread subclass and not the thread that object lives in.
[/quote]

What's the example you're talking about? And "from the thread subclass" doesn't mean much; as I said, adding a method which in turn calls start() and calling that method is fine (and I doubt start() is getting called from inside run()).

Satmosc

peppe: Check examples from QtSources Threading/queuedcustomtype
and in file "renderthread.cpp", Line 66:

@//![processing the image (start)]
void RenderThread::processImage(const QImage &image)
{
if (image.isNull())
return;

m_image = image;
m_abort = false;
start();

}@

dangelog

That processImage method gets called from the right thread (in the example, the GUI thread, which is where the RenderThread object is living), so it's safe to use that way.