[Interest] Signals, slots before the event loop starts?

[Jason H]

> Sent: Thursday, April 11, 2019 at 7:35 AM
> From: "Giuseppe D'Angelo via Interest" <interest at qt-project.org>
> To: interest at qt-project.org
> Subject: Re: [Interest] Signals, slots before the event loop starts?
>
> Il 11/04/19 00:18, Jason H ha scritto:
> > In a QObject who is exported to QML, and is instantiated just below the top-level Window:
> > //  in the object's open() method:
> > if (!_serialPort.open(QIODevice::ReadWrite))
> > 	qApp->quit(); // won't actually quit - no use if I can't use the serial port. (because another instance is using it)
> >
> > Then I have a ready() signal that is emitted when the serial device is ready, however the QML, when I hook onReady, it never gets called. I have to use a Component.onCompleted at the top level. However, there is async serial I/O happening, so there is at least one event loop?
> >
> > What can I do to make sure these things work?
>
> Regarding quit(): calling it before exec() has been called yields no
> effects. This is documented:
>
> > https://doc.qt.io/qt-5/qcoreapplication.html#quit
>
> > If a signal connected (non-queued) to this slot is emitted before control enters the main event loop (such as before "int main" calls exec()), the slot has no effect and the application never exits
>
> So, instead of calling quit() directly, do a queued invocation.

What is the best way to do that? I think in the past, I used a 0ms timer, but that always feels janky.

>
> Regarding ready(): can't say more without looking at the code. You need
> to make a minimal testcase.

It's rather simple, port opens when the portname property is set during initialization. The device writes a ready message that i detect and emit (somehow... I don't know how I process it in readyRead handler without an event loop, but it happens). I emit ready() and the QML handler for ready does not get invoked.

> Anyhow, all events queued before running exec() will get dispatched when
> you enter the event loop. The problem with e.g. quit() is that it does
> not involve sending events at all, it involves setting a flag into the
> event loop. Flag that is never read because the event loop is not running...

That seems janky as well. Why not give it it's own message? Even windows has WM_QUIT.