QObject has no event loop, the event loop is in QCoreApplication and siblings. You can not just stop the one from you main application. As for QThread you can interrupt the thread but I'm really not sure that's the best way to handle your situation. From the looks of it, you seem to have to create a queue of the events received and store these there while in pause mode and then empty that queue on restart if that makes sense.

@comy said in Does QWebEnginePage::load() start a new event loop internally or it just calls processEvents() ?: @JonB Starting a new local event loop is done by executing QEventLoop::exec(). Oh I see, just QEventLoop::exec(). Yes, I had tried that. According to me it made no difference, and deleteLater()s of QWebEngine stuff still didn't free till execution got back to my top-level Qt event loop. Didn't understand why, your mileage may vary :)

Even two if you take the QtScxml module. Well, I am not behind the design of the system so I can just offer some thoughts. I would say that if you need that level of control of the event loop, you might not be using the right tool for your use case.

@Christian-Ehrlicher The thread don't get autodeleted once it runned its empty function? o.O I need to test it! :D

Events are not posted to a particular instance of an event loop object. They are posted to a thread. An event loop object does not "own" any events. It's basically a while loop that calls processEvents of a per thread event dispatcher. That being said if you nest event loops they all process the same pile of events. It's just that only the top one gets to do it while the calling ones wait for it to return.

Thank you very much! :-)

@Buckwheat Thank you documents link. I will read it and trying to make change in my code. thank you @Buckwheat .

@SGaist I wish mean throw this message : QEventLoop: Cannot be used without QApplication But this problem is no more. I have delete the project and create un other without dll... It's not the best solution but it's gona work.

@QtExchange Forgot to link those two, which are very important to understand before working with threads: QObjects' thread affinity: http://doc.qt.io/qt-5/qobject.html#thread-affinity Queued connections accros threads: http://doc.qt.io/qt-5/threads-qobject.html#signals-and-slots-across-threads

You can find the implementation in qtestsystem.h It basically trigger event processing and sleeps a short time. Can you show a picture of how your system should work ?

Hi and welcome to devnet, That's because you are calling exec on _eventLoop twice. You should rather use a local QEventLoop or not allow the query to start if already in progress.

I never tried to start a thread with event loop in a program without main event loop (QApplication). My guess: it will work inside your thread, but you will not be able to communicate with the thread from main thread using signals/slots.

Ok guy thank you for that much replies :P! I solved the issue by myself anyway. In case sombebody has a similar problem here comes the solution: What I did wrong was that I connected a time consuming function to the UpdateClient::tcpReady() slot. In this function I did some stuff which also lead to the emission of UpdateClient::tcpReady(). This broke the QEventQueue. So to what I had to chance was to skip the direct signal slot connection an do this in the UpdateClient::tcpReady(): QTimer::singleShot(0, this, SIGNAL(updateAvailable())); No everything is working fine ;).

@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 Hi. Thank you for your help. I'll give it a try, but I still don't get why my code doesn't work... If anyone could take a guess, I'd appreciate.