Yes you are right, i have tested what you said and tried to get the id from inside a function that was executed after the thread has started and it gave me the id of the new thread, Thank you for your time.

@drbroly It's been a while since I used openCV, but if I remember correctly, Iused the default settings for it and that ought to be CPU-computation. That work was for an android app, in a time, when QCamera did not work properly, QML-Videoframes were not handled correctly in cpp-code and openCV-Camera driver were horribly outdated. Let's say I had happier moments in my career. Those I remember better ...

After a lot of try and error, mostly error and crashes, i ended up with this working solution: foreach(FTPDownload* w, g_Worker) { if(w->_working) { w->abort(); // sets _working = false and _abort = true w->ftp->deleteLater(); // ends the QFtp download w->thread()->quit(); w->thread()->deleteLater(); } } The only problem left is when i remove the table from the QTableView the progress update wont terminate and the app crashes, because the table does not exist anymore. I guess i have to add the the function that executes the code from above somehow in a event loop so the code after that deletes the table wont be executed before all the downloads are really stopped. Right?

I agree, this while() was bothering me. I'm using a _timer with QTimer where start() by clicking, I get the Socket data with onReadyRead() process met _timer.stop() but emito sign for the status, seems to be working well. But I accept suggestions for improvement, but I removed the loop while()

Hi, Are you using the exact same code as the book ? One thing that is puzzling in the error is that it seems that at some point you are trying to copy a QThread which is not possible since it's a QObject derived class.

@zzaj No problem. Good luck with your project!!

@alex_malyu Thank you. In fact that was what I thought too, I was just worried, since I read that processEvents() [...] can cause a lot of unexpected issues if your code is not reentrant. Here it says that it [...] makes the application react with delays to events. Furthermore the code is difficult to read and analyze, therefore this solution is only suited for short and simple problems that are to be processed in a single thread, such as splash screens and the monitoring of short operations. In response to this, I can say that, graphically speaking, the application works really well indeed, without delays (for example when I press a button to stop the execution). Here it is said that you can call this function occasionally when your program is busy performing a long operation. But, in the event that you are running a local loop which calls this function continuously, without an event loop, the DeferredDelete events will not be processed. As far as I know, this is not my case, since I do have an event loop (I think) in the main.cpp, in which I have return a.exec();: int main(int argc, char *argv[]) { QApplication a(argc, argv); MainWindow w(setUpParser(&a)); w.show(); return a.exec(); }

I fix this problem with signals and slots, but I firts create what a call a log, and after one minute a close that log. I'm getting this error while closing the log QEventLoop::exec: instance 0x8d4418 has already called exec()

@JKSH Thanks--this helped me solve the problem. In a GUI thread, I was using exit()--when I should have just used emit finished()