When is QEventloop member needed in a class ?

[Shimmering]

Hi guys
Recently I've been studying about event loop of Qt. And I chanced upon some "local event loop" thing. I wonder when is QEventLoop needed (maybe used as a class member? How?). And what can I do with this class ?

[SGaist]

Hi,

It's used for example when you call a QDialog exec function.

It's essentially when you need your program to do something involving signals and slots before going further. Before using it, you should also consider the QStateMachine framework.

[MuldeR]

Just for example: Imagine you have some function, called from your main thread, that needs to wait for 10 seconds, for whatever reason. Of course you could put a simple Sleep(10000) in that function. But that would "block" your GUI and make your application appear unresponsive, because the main thread won't process any events while its sleeping! Instead, you could use a local event loop, in order to make your function "wait" while keeping the GUI responsive:

@QEvenLoop loop;
QTimer::singleShot(10000, &loop, SLOT(quit()));
loop.exec(QEventLoop::ExcludeUserInputEvents);@

[Shimmering]

Is there any chance that I would use QEventLoop class in self-defined class as a member ?

Can you explain a bit more about

"It’s essentially when you need your program to do something involving signals and slots before going further. Before using it, you should also consider the QStateMachine framework." ?

I'm not sure that I got it right. It seems to me that the signal and slot scheme and the event loop thing are realized along two different ways. And what's the relationship among signal/slot, event loop and QStateMachine ?

Thanks a lot !
[quote author="SGaist" date="1398266171"]Hi,

It's used for example when you call a QDialog exec function.

It's essentially when you need your program to do something involving signals and slots before going further. Before using it, you should also consider the QStateMachine framework.[/quote]

[SGaist]

As member ? Not really, it's more something that you will used locally in a function.

Mulder explained it very well.

In this case, just a decision when creating your class. Depending on the design a local event loop might be good, but based on your needs, a state machine might be better.

[Shimmering]

Sorry for late reply.
Due to the slow network situation, my original reply did not post.

I see what you mean. And I try a local QEventLoop in my Button::Clicked() slot. It seems to me that it does not affect the response of the main GUI, which makes me curious about the relationship between local event loop and main event loop. Can you tell me the difference ?

[quote author="MuldeR" date="1398299281"]Just for example: Imagine you have some function, called from your main thread, that needs to wait for 10 seconds, for whatever reason. Of course you could put a simple Sleep(10000) in that function. But that would "block" your GUI and make your application appear unresponsive, because the main thread won't process any events while its sleeping! Instead, you could use a local event loop, in order to make your function "wait" while keeping the GUI responsive:

@QEvenLoop loop;
QTimer::singleShot(10000, &loop, SLOT(quit()));
loop.exec(QEventLoop::ExcludeUserInputEvents);@[/quote]

[MuldeR]

As soon as you start your GUI application, by invoking QApplication::exec(), the global event loop will be running. And most of the time you do not need to create another one! But be ware that, as soon as some function is called in the main thread (for example: a slot is invoked after the user clicked a button), the global event loop will not be able to process any events - until the functions returns to the global event loop. Again, most of the time you don't need to worry, because most functions return quickly. But in some cases, you may which to process events inside your own function (e.g. slot). And in this case, a local event loop might be used. Just as in the example above.

Side note: If you have calculations or tasks that take a long time, it is usually preferable to move those calculations/tasks into a separate "background" thread. This way they can run without interfering with the main event loop.

__

As far as signal delivery is concerned, the event loop is not required for "direct" connections - because in this case the slot will be called directly as soon as emit is invoked. But for "queued" connections, the signal is only enqueued into the receiver's queue! The slot will be called, eventually, from the event loop of the receiver thread. Obviously, this requires the receiver thread to run an event loop. But again, you usually don't need to create a local event loop in the main thread in order to process "queued" signals from other threads. That's because the global even loop will be take care of that.