i did a very bad mistake...

The mistake is creating two instance of workerThread class, so connection returns true because of the instance of workerThread is just emitting but other instance is just connecting. So it needs to be only one instance and one connection in my case.

added to workerthread.h:

extern workerThread *t1;

changed in workerthread.cpp

emit t1->sendLocationsFromThread(x, y, w, h);

changed in mainwindow.cpp

bool callBackThreadConn = connect(w1, SIGNAL(sendLocationsFromThread(int, int, int, int)), this, SLOT(onLocationChanged(int, int, int, int)));

it's ok now, data can be send to GUI

Hi,

The terminate as it names suggest kills the the thread so it's state is not guaranteed as mentioned in the documentation.

Not that you are automagically destroying everything once your operation is done. See your connections to the deleteLater slots.

You're welcome !

Since you have it working now, please mark that thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :)

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?

@kshegunov thanks a lot!

@mistralegna

Thanks, it's exactly the answer I was waiting for.

I'm glad. :D

Thank you a lot for your answers!

You're welcome.

How can i create my signal for text edit with python3 ?
With as many ways i tried, but I did not succeed .. :(

@SGaist said:

Hi,

@SysTech : deleteLater won't remove things when the thread is done, but at the next event loop iteration.

Thanks. I wasn't exactly sure when it deleted it but good to know!

@JKSH
Oh, did not catch that difference. Thank you.

I would have expected that all Qt type are already registered. However, this is a template which you registered with template argument. That is presumably the reason. A template delivers infinite possibilities. I did not know.

Yep, you've helped me realize that this is one of those cases where it's not worthwhile to reinvent the wheel. Thanks for your help!

@ChrisW67

Thank you for you help.
Probably the thing is, QSerialPort has a problem to work in a new thread.

I can handle the other QObject in a new thread very well, and the exception only happens when the Object contains QSerialPort.
Also, in my last post, I actually never user QList, although Qt tells me something wrong with QList.

I have given up on working serialThread. QSerialPort does work good in the main thread.

@SGaist

Thank you very much for your tips!
I probably should give up on the serial thread. It is beyond my ability to play with that problem.

Hace poco tuve que usar QThreadPool, el uso básico sería este:

// Puede ser una función tradicional o un método estático. // func puede recibir hasta un máximo de 5 parámetros. void func(QMutex *mutex, otrosParametros) { mutex->lock(); // Hacer lo que haya que hacer aquí. mutex->unlock(); } int N = 1000; QThreadPool threadPool; // El mutex se usa para bloquear la modificación simultanea // de prametros globales. QMutex mutex; for (int i = 0; i < int; i++) { QtConcurrent::run(&threadPool, func, &mutex, otrosParametros); } threadPool.waitForDone(); // Hacer algo con el resultado de los threads.