Is there a signal that triggers right after .exec() is called
-
I´m building a new custom splash screen, which - in developer mode only - can also show the current log file to help them setting the software up properly (embedded system).
In the old version, parsing of all config files happened before the splash screen was even shown. But now I need this to happen right after it is displayed, so .exec() can be called to allow user interaction on the splash screen. So I need a way of triggering code to start parsing all config files, right after .exec() was called.
Whats the best way to do this? Using a single shot timer is one option, but if I use zero time, it can trigger before .exec() takes over ? And if I set any time (like 1s), I may be wasting startup time, which is limited.
I was also thinking about using postEvent(), but the documentation is not that clear for me, if it does what I want.
So the important part is - I need a way to execute some code, which is guaranteed to be called right after .exec() was called (and not x seconds later).I´ve googeled for it, but seem to always use wrong key words, cause nothing useful came up so far.
Any suggestions? -
@CHoelzl said in Is there a signal that triggers right after .exec() is called:
I need a way to execute some code, which is guaranteed to be called right after .exec()
I think you can override showEvent(QShowEvent *event)
and execute your code from here. -
@CHoelzl said in Is there a signal that triggers right after .exec() is called:
Whats the best way to do this? Using a single shot timer is one option, but if I use zero time, it can trigger before .exec() takes over ?
If you mean Q(Core)Application::exec() then no - a QTimer needs a running event loop.
-
Just to be sure, this means, if I set up a single shot timer with 0 delay time right before calling app.exec(), it will be called 100% after .exec(), when the event handler takes over? That is exactly what I am looking for.
-
Even though a 0 delay timer does get called immediately, I am not entirely sure how that will interact with the splash screen. The splash screen needs to run in the main thread and might be blocked by you loading the config files (depends how long loading the config files takes if this will be an issue). Though, a 0 delay timer will execute when the event loop is idle. This means that at least the
show()
for the splash screen will be executed before loading the config files. However, if the user switches back and forth between other applications and the splash screen, your app might be identified as hanging and not update the splash screen (maybe leaving a white rectangle).