Thank you all for the valuable information you have given me! In the end I got around the inability to use the main event loop by running my new part on a separate thread, with this pattern: QThread myThread; MyNewPart newPart; newPart.moveToThread(&myThread); /* Connect(...) QThread::started -> MyNewPart::run*/ myThread.start(); Everything works without changing the code :)

@texasRanger Why do you think you need an additional event loop? From your description I don't see any need for it. If file is changed you will get a signal from file watcher. You just need to make sure parsing of that file does not take too long.

@Dariusz said in QEventLoop - unique event?: well I have no idea how to solve it now... You said this is some kind of cumulative transformation you're doing, right? What about keeping only the info about the transform instead of actually doing it. Then on the update event you can calculate the accumulated result. Say you're moving a thing in space, you can keep the offset from the original position, you don't need to actually do to the move yet, just sum up the vectors. Finally construct the transformation matrix and apply. The same thing could be done for rotations, skews etc. The only thing that you need to be careful about, however, is that affine transforms aren't commutative. If you have move and then rotate, you can't invert the order to rotate and then move. Either way you can process the similar transformations in batches based on similarity. PS. I went on a limb here, as I have no clue what you're doing exactly. If you provide more info, we may end up suggesting something better.

@Dariusz Sorry to make a post to just confirm what @SGaist has said above, but 20 * 75 == 1,500-odd line edits average. That's a lot! (And I pity the user who has to fill those in ;-) ) I think the suggestion that you look at the possibility of some kind of table instead needs reiterating. And @VRonin will then be here to ensure that you achieve this using item delegates instead of widgets in your table, so it will all be fast and not use up too much memory/resources ;-)

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.