> Sent: Thursday, April 11, 2019 at 7:35 AM > From: "Giuseppe D'Angelo via Interest" <interest@qt-project.org> > To: interest@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. _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
