Nominate our 2022 Qt Champions!

RemoteObjects get replicas without waitForSource() doesn't work.

  • Hello,

    I've got a Remote Object server-client application.
    I use QRemoteObjectNode::connectToNode(URL) which is successful:

    this->_client_node = QSharedPointer<QRemoteObjectNode>::create();
    bool node_connect_successful = this->_client_node->connectToNode(url);
    if(!node_connect_successful) return;

    After that I successfully get a replica pointer using

    this->_rep.reset(_client_node->acquire<blablaReplica>("Master object");

    The type of _rep is QSharedPointer<blablaReplica>
    Now here's the issue:
    After I got the replica pointer I have to do a _rep->waitForSource(); and everything like calling remote functions and getting remoteReplys and so on works.
    If I instead do a

    connect(, &QRemoteObjectReplica::stateChanged, this, &Client_model::on_replica_state_changed);

    and try to work with the replica in the slot when state is QRemoteObjectReplica::Valid, all operations on the slot fail, even though the replica's state is the same as after the waitForSource().
    This is in Qt5.11.1.
    The problem with waitForSource() is, that it blocks until the server connection is established or until timeout.
    So, what's the proper signal of RemoteObjectReplica to wait for? The documentation states the ::Valid state gets set only after the connection is ready, the replica initialized and everything ready to go.

    Thanks in advance.

  • @TAdler
    I've begun working with QRO myself. I've found that waiting on the initialized() signal from the replica is fairly reliable. Then inside the slot I check for isReplicaValid().

    I'm getting odd results from using waitForSource(), but I'm also on 5.11.x and will wait until I try it with 5.12 to see it behaves better.

  • Ah thanks. I could try that. Only what do you do if the replica is not valid at that point? The initialized signal won't trigger again if it becomes available, right?

  • I got it.
    The solution was to force a Qt::QueuedConnection in the connect call for the ::stateChanged signal.
    Since the replica and Client-model objects live in the same thread, with Qt::AutoConnection a direct connection is established.
    However, that skips returning to the main event loop in between the calls.
    When I instead called waitForSource(), an internal event loop in that function is created.
    Even though the state of the replica object is designated as being valid when the slot is called, it is necessary to call an event loop at some point for the replica state to really become working.
    I consider this a bug in Qt Remote Objects or at least a missing important point in the docs for the replica object.

Log in to reply