18
votes

I have a Qt application with this kind of main()...

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    MainWindow   mainWin;

    ... A separate, non-GUI thread is launched here

    mainWin.Init();
    mainWin.show();

    app.exec();
}

This other thread that is created before the mainWin needs to know when it can start communicating with the mainWin. But since the mainWin uses Qt signals, slots, timers, etc, it's not truly ready to rock until the event loop is running (via exec()).

My question is: is there some signal or event that is emitted when the event loop has started?

Consider this. In mainWin.Init(), you can create something like a QTimer and even call .start() to kick it off. But it won't actually be run and trigger events until exec() has been called. This is why I need to know when the event loop has truly started.

3
Is your thread a Qt thread or native?UmNyobe

3 Answers

15
votes

You can send a signal to your window before the exec() call. This will place an entry in app's signal queue. When exec() is running, the signal will be delivered and your window will know that the event loop is running.

A simple way would be to use QTimer::singleShot(0, &mainWin, SLOT(onEventLoopStarted())); which connects to a custom slot of your window class.

2
votes

Since emitted signals don't get lost when the event loop is not yet running, your thread may not necessarily need to know when your window is ready.
Your thread could start sending signals to the window right away but it will only receive signals from the window when the event loop is running.

1
votes

You can do it in the following order:

QApplication app(argc, argv);
Mainwinwdow mainWin;
QThread yourThread;

//connect the signals from the thread to the mainWin here

mainWin.Init();
mainWin.show();

yourThread.start();

return app.exec();