[Interest] using a custom class as parameter of signal/slot, used in QML
godboutj at amotus.ca
Fri Mar 1 17:25:27 CET 2019
Since signal are not sync all the time but can be async, the argument need to be copiable to allow this. So you need to be able to copy the arguments on the signals. Therefore the QObject is not copiable, they cannot be passed as arguments directly, you need a pointer. The ownership and lifetime of that object is up to you, but you need it to live until all handler have finish processing the signal (this can be longer then the signal emit for queued connection).
If you can easily copy the structure you probably can serialize/deserialize it or put it into a QVariant, QVariantList or QVariantMap. That would be copiable.
From: Sylvain Pointeau <sylvain.pointeau at gmail.com>
Sent: March 1, 2019 11:15 AM
To: Jérôme Godbout <godboutj at amotus.ca>
Cc: Qt Project <interest at qt-project.org>
Subject: Re: [Interest] using a custom class as parameter of signal/slot, used in QML
On Fri, Mar 1, 2019 at 3:34 PM Jérôme Godbout <godboutj at amotus.ca<mailto:godboutj at amotus.ca>> wrote:
The fact that the QObject is non copiable, is one of the reason it need a pointer (which can be copied). As for the ownership, you can check with the qqmlengine:
I have understood it yes
You can change the ownership too with setOwnership(). I for one exposed the methods to Qml so each side can check/set the qobject ownership based on the needs. This is very helpful to debug.
You can use QPointer to have a pointer that will return to null if the qobject get deleted.
OK but I thought a signal should be quite generic, and not necessarily consumed by QML.
but maybe we should design special signals for QML, is this what you suggest?
I would find more convenient to be able to send a structure by copy, so consumed as it is by QML (wrapped in QML and ownership set to QML)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest