Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. RemoteObjects get replicas without waitForSource() doesn't work.
QtWS25 Last Chance

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

Scheduled Pinned Locked Moved Unsolved General and Desktop
4 Posts 2 Posters 822 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T Offline
    T Offline
    TAdler
    wrote on last edited by
    #1

    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(_rep.data(), &QRemoteObjectReplica::stateChanged, this, &Client_model::on_replica_state_changed);
    return;
    

    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.

    mranger90M 1 Reply Last reply
    0
    • T TAdler

      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(_rep.data(), &QRemoteObjectReplica::stateChanged, this, &Client_model::on_replica_state_changed);
      return;
      

      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.

      mranger90M Offline
      mranger90M Offline
      mranger90
      wrote on last edited by
      #2

      @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.

      1 Reply Last reply
      0
      • T Offline
        T Offline
        TAdler
        wrote on last edited by
        #3

        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?

        1 Reply Last reply
        0
        • T Offline
          T Offline
          TAdler
          wrote on last edited by
          #4

          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.

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved