[Interest] QRemoteObjectDynamicReplica: How get a slot return value?
Stottlemyer, Brett (B.S.)
bstottle at ford.com
Thu Aug 8 21:37:21 CEST 2019
The constructor is private because you aren’t intended to create the dynamic replica directly, you must get it from a node. The object won’t be valid until it receives an initial state from a source in another node, so the nodes must be connected together.
Once the node is initialized, you can use Qt’s introspection methods to understand the properties, signals and slots available.
A usage example can be found in the tests, here:
Using dynamica replicas is available, but is generally much more difficult than using repc. So repc is certainly recommended for most use-cases.
From: Interest <interest-bounces at qt-project.org> On Behalf Of Daesdemon
Sent: Thursday, August 8, 2019 3:03 PM
To: interest at qt-project.org
Subject: [Interest] QRemoteObjectDynamicReplica: How get a slot return value?
Hi Qt people,
I have been advised to post this kind of question on the maillist instead of forum. If it is the wrong place, please, forgive me.
After digging in REPC generated code and RO sources, i found there is some "kind of magic" in the REPC code:
- The call of returning value slot in REPC generated object use the protected sendWithReply function of QRemoteObjectReplica (async call, returning a kind of future object: QRemoteObjectPendingReply<T> with T of the ReturnType of the slot)
The problem is that the QRemoteObjectDynamicReplica have no public constructor, so no way to use this function even by derivation.
The slot signature in the dynamic replica metaobject also has no functor parameter to get the return value async. In fact the signature even loose the ReturnValue Type.
So how could we get a slot return value from a dynamic Replica ?
If there is no way (without re-coding a large part) to do this, I find this lack of feature really troublesome in my case, where the main spec is to have no use of REPC.
A subsidiary question could be : Why is the QRemoteObjectDynamicReplica(QRemoteObjectNode *node, const QString &name) constructor private ?
If public, it would allow to overload acquireDynamic in QRemoteObjectNode and extend QRemoteObjectDynamicReplica by derivation, for, in this case, expose internally the sendAndReply function.
However the lack of the return value type would still be a problem.
I understand principle of encapsulation but i am in dead-end there.
If someone had a clue, i'll take it gratefully.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest