Hi, Please use coding tags for your code, that will make it readable. You are using several different instance of sps2data that are unrelated to each other. On a side note, you should always instanciate QXXXApplication before any other QObject based classes.

Hi, In addition to @Christian-Ehrlicher, what exactly are you trying to achieve ?

@amina I posted this in an other forum because it has been a while that I am stuck and it has to be fixed .. I am going to share the solution it may help someone https://stackoverflow.com/questions/66869600/timer-couldnt-work-with-wiringpiisr-qtquick-application/66873812?noredirect=1#comment118230663_66873812 static instances of QObject are also not supported so the instance vitesse should be created after QApplication. this will fix the problem : static void isrInput_vitesse(); static Capteur_Input *vitesse = nullptr; static void isrInput_vitesse() { if(!vitesse) //not initialized yet return; QMetaObject::invokeMethod( vitesse, "isrCallback", Qt::QueuedConnection ); //or blockingQueue if you need to handle it directly in Qt way. } and in the main fucntion int main(int argc, char *argv[]) { QApplication a(argc, argv); //..... your main application body vitesse = new Capteur_Input(Pin_vitesse,PUD_OFF,INT_EDGE_RISING,isrInput_vitesse); ctx->setContextProperty("vitesse", vitesse); //... } the function isrCallback should be a slot

@KroMignon I will fix it thank you

@suslucoder said in QtCharts::QLineSeries(0x2ea7560, There is no data on chart: error says QtCharts::QLineSeries(0x2ea7560) What "error"? qDebug()<< series; Maybe QtCharts::QLineSeries(0x2ea7560) is what that prints when you ask it to print a QLineSeries *? Since it is a pointer, maybe you intended to go qDebug()<< *series;?

@suslucoder

@Jonas-Kvinge Oh, yes. I fixed it. Thank you

@JonB said in How can read input from a txt and write them to another txt file?: Either I'm going mad and you did not delete it Sorry, I restored it without any notice here :)

Hi 10.000 items take some time to create and add. Print_Descendants_key must not touch/access the ListWidget from the other thread. that will not be good. To make the UI less hanged while adding such a number of items, you can do 3 things. 1: use a View + custom model instead. If you already have all the data in a list/vector, a custom model on top of that would be super fast. 2: Use a thread to send data to main. Make sure the thread is not hammering the main gui as that would lag too. You can also use a QTimer and simply slow down the adding. 3: Do the ugly trick of calling QApplication::processEvents() (in the loop that adds the items) to allow the main GUI to be more responsive.

@learnist please don't double post.

@Alain38-0 said in QSqlDatabase and upgrade to Qt5.12: Unfortunately with Qt5.12 nothing works. Because the database must be now in the same thread that the process using it. I'm surprised it used to work at all. So far as I understood, it was always the case that database access had to be in same thread as where database created.

@mrjj Thank you, thank you, thank you. It is always a pleasure to work with someone who knows their stuff. I had overlooked the step of connecting FortuneServer's signal to Dialog's slot in the dialog. I added in dialog.cpp: connect(&server, SIGNAL(connectionMade(QString)), this, SLOT(setConnectionText(QString)) ); Once I put this in, it worked like a champ! Marking it solved. Thanks again.

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

@efiLabs I am facing same kind of problem. I working on my linux laptop (ubuntu 18.0). I have run an application in cetral mode of ble. When this application is started to receive the data it receive some 20 packets of 509 bytes chunks and then after it hangs. When i googled it, i realized it may be the problem of throughput. Is there any api in Qt to tell the peripheral device to send the data in low throughput ?

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.