OP doesn't give enough information to indicate what is best strategy: event dispatch, timer execution, or threads.

@JonB

Thank you for your guidance.
I was able to solve this issue with your help.

For others facing this issue:

The connect() function that worked for me was:

QObject::connect(&futWatch, &QFutureWatcher<int>::finished, this, &myClass::onFinished);

And the onFinished() function was the same as suggested by Jon

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
alt text

@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 :)