@Ekia said in Never ending local Event Loop:

How would you suggest to post the request after starting the local event loop? Because as soon as I'm calling exec(), the execution is blocked there (sorry, I think that I missed something in your suggestion).

You could use QMetaObject::invokeMethod to place something into the local event loop even before it is run. I would usually put the current code into a lambda and place that lambda into the event loop using invokeMethod. (So, the invokeMethod would be done before calling exec().)

@Ekia said in Never ending local Event Loop:

Actually, I'm also thinking about an alternative solution with processEvents() + a timeout, but I'm not sure if it's the right way to go.

In that case I would use QTime (there used to be something like QTime::elapsed(), which in Qt 6 I would now replace with msecsTo(QTime::currentTime())). Usually, processEvents is not a good idea because it will slow your application down. However, if you are already willing to wait up to 10 seconds, maybe it is not too bad. I wish slots could be coroutines so that they are async, but you could write them as if they were synchronous (just with an occasional co_yield).

Drag and drop has never worked very well in QtWebAssembly.
But it is working in 6.6.0beta1 single threaded release.

You need to use asyncify though:
https://doc.qt.io/qt-6/wasm.html#asyncify

Good news is, you no longer have to rebuild Qt to get asyncify, you just need to add a linker argument.
cmake: target_link_options(<target> PUBLIC -sASYNCIFY -Os)
qmake: QMAKE_LFLAGS += -sASYNCIFY -Os

The issue is that you are handling the incoming data as if you would get full frames every time you receive something. There's no guarantee for that. Hence you should fix your buffer usage. Cumulate all the data until you know you have a full frame ready to be parsed further.

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.

@nintyfan said in Creating widgets in "another" thread...:

Signal is not solution, because QApplication::exec could not been called yet

So how do you show the push button then? Your design looks flawed.

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 ;).