Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. Brainstorm
  4. identifying signal senders

identifying signal senders

Scheduled Pinned Locked Moved Solved Brainstorm
17 Posts 6 Posters 3.1k 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.
  • M mzimmers
    26 Apr 2023, 11:48

    @JonB I suppose that's an option. Of course, each model would have to have the same handler signature, but that's probably best practices anyway. I suppose I could take it a step further, and pass a pointer to the handler function instead of the entire object?

    J Offline
    J Offline
    JonB
    wrote on 26 Apr 2023, 12:10 last edited by
    #8

    @mzimmers Of course, whatever you need to identify it when the response is received.

    1 Reply Last reply
    0
    • M mzimmers
      26 Apr 2023, 11:48

      @JonB I suppose that's an option. Of course, each model would have to have the same handler signature, but that's probably best practices anyway. I suppose I could take it a step further, and pass a pointer to the handler function instead of the entire object?

      S Offline
      S Offline
      SGaist
      Lifetime Qt Champion
      wrote on 26 Apr 2023, 19:12 last edited by
      #9

      @mzimmers hi, QNetworkReply being a QObject, you could set the signal sender as dynamic property on it. You can then retrieve it when processing the result.

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      M 1 Reply Last reply 26 Apr 2023, 23:47
      0
      • S SGaist
        26 Apr 2023, 19:12

        @mzimmers hi, QNetworkReply being a QObject, you could set the signal sender as dynamic property on it. You can then retrieve it when processing the result.

        M Offline
        M Offline
        mzimmers
        wrote on 26 Apr 2023, 23:47 last edited by
        #10

        @SGaist right, but it's the same problem -- what do I do with it? How do I go from knowing the sender to invoking a method in the sender class?

        J 1 Reply Last reply 27 Apr 2023, 07:31
        0
        • J Offline
          J Offline
          jeremy_k
          wrote on 27 Apr 2023, 03:12 last edited by
          #11

          Return the QNetworkReply from MessageMgr::sendGet(), connect the appropriate model slot to QNetworkReply::finished(), and eliminate the intermediary handling of the reply.

          Another alternative is QNetworkRequest::setOriginatingObject() and QNetworkReply::originatingObject().

          Asking a question about code? http://eel.is/iso-c++/testcase/

          1 Reply Last reply
          1
          • M mzimmers
            26 Apr 2023, 23:47

            @SGaist right, but it's the same problem -- what do I do with it? How do I go from knowing the sender to invoking a method in the sender class?

            J Offline
            J Offline
            JonB
            wrote on 27 Apr 2023, 07:31 last edited by JonB
            #12

            @mzimmers said in identifying signal senders:

            @SGaist right, but it's the same problem -- what do I do with it? How do I go from knowing the sender to invoking a method in the sender class?

            Again, I don't understand. I wrote earlier for this suggestion:

            Subclassing QNetworkRequest could allow you add a QAbstractItemModel * to directly identify the data model.

            So you would have a pointer to the model as a QAbstractItemModel *. On which you can call (QAbstractItemModel) methods directly. Or if your models share some other common interface you could derive them from YourModelBase and pass that as parameter to be able to call its methods. Or you could use qobject_cast<SpecificModelType *> to test their type and call specific model methods.

            Or the approaches @jeremy_k mentions. Using QNetworkRequest::setOriginatingObject(someModel) saves subclassing if you don't want to do that, but it's the same approach. His direct connection of finished signal could be used if you do not actually want/need the manager to see/handle the replies.

            One way or another you can either have the models send an identifier for themselves to the manager, which then routes replies to the model from that, or you can have the manager return the QNetworkReply * from QNetworkAccessManager::get() to the model and that puts e.g. a slot on QNetworkReply::finished() to its own code.

            J 1 Reply Last reply 28 Apr 2023, 08:06
            1
            • J JonB
              27 Apr 2023, 07:31

              @mzimmers said in identifying signal senders:

              @SGaist right, but it's the same problem -- what do I do with it? How do I go from knowing the sender to invoking a method in the sender class?

              Again, I don't understand. I wrote earlier for this suggestion:

              Subclassing QNetworkRequest could allow you add a QAbstractItemModel * to directly identify the data model.

              So you would have a pointer to the model as a QAbstractItemModel *. On which you can call (QAbstractItemModel) methods directly. Or if your models share some other common interface you could derive them from YourModelBase and pass that as parameter to be able to call its methods. Or you could use qobject_cast<SpecificModelType *> to test their type and call specific model methods.

              Or the approaches @jeremy_k mentions. Using QNetworkRequest::setOriginatingObject(someModel) saves subclassing if you don't want to do that, but it's the same approach. His direct connection of finished signal could be used if you do not actually want/need the manager to see/handle the replies.

              One way or another you can either have the models send an identifier for themselves to the manager, which then routes replies to the model from that, or you can have the manager return the QNetworkReply * from QNetworkAccessManager::get() to the model and that puts e.g. a slot on QNetworkReply::finished() to its own code.

              J Offline
              J Offline
              jeremy_k
              wrote on 28 Apr 2023, 08:06 last edited by
              #13

              @JonB said in identifying signal senders:

              His direct connection of finished signal could be used if you do not actually want/need the manager to see/handle the replies.

              The struck-out portion is inaccurate. The manager can view the reply status via any of the const methods, or read content via QIODevice::peek() without interfering with later connections to the finished or readyRead signals.

              Asking a question about code? http://eel.is/iso-c++/testcase/

              J 1 Reply Last reply 28 Apr 2023, 08:51
              0
              • J jeremy_k
                28 Apr 2023, 08:06

                @JonB said in identifying signal senders:

                His direct connection of finished signal could be used if you do not actually want/need the manager to see/handle the replies.

                The struck-out portion is inaccurate. The manager can view the reply status via any of the const methods, or read content via QIODevice::peek() without interfering with later connections to the finished or readyRead signals.

                J Offline
                J Offline
                JonB
                wrote on 28 Apr 2023, 08:51 last edited by JonB
                #14

                @jeremy_k
                Yes, but that's not what's meant. It's a question of whether the OP wants the replies routed through the manager, possibly to choose whether to send on to the models or to ignore/not do so, or whether the model receives the finished regardless and acts on it. I said "could" be used if OP does not want manager to see/handle the replies, not that it would preclude the manager seeing the responses as you wrote. As you said, not attaching the finished() signal to the model to "eliminate the intermediary handling of the reply" means that it will be attached and handled by the manager as "intermediary". Depends what the OP wants,

                J 1 Reply Last reply 28 Apr 2023, 09:04
                0
                • J JonB
                  28 Apr 2023, 08:51

                  @jeremy_k
                  Yes, but that's not what's meant. It's a question of whether the OP wants the replies routed through the manager, possibly to choose whether to send on to the models or to ignore/not do so, or whether the model receives the finished regardless and acts on it. I said "could" be used if OP does not want manager to see/handle the replies, not that it would preclude the manager seeing the responses as you wrote. As you said, not attaching the finished() signal to the model to "eliminate the intermediary handling of the reply" means that it will be attached and handled by the manager as "intermediary". Depends what the OP wants,

                  J Offline
                  J Offline
                  jeremy_k
                  wrote on 28 Apr 2023, 09:04 last edited by
                  #15

                  @JonB said in identifying signal senders:

                  @jeremy_k
                  Yes, but that's not what's meant. It's a question of whether the OP wants the replies routed through the manager, possibly to choose whether to send on to the models or to ignore/not do so, or whether the model receives the finished regardless and acts on it. I said "could" be used if OP does not want manager to see/handle the replies, not that it would preclude the manager seeing the responses as you wrote. As you said, not attaching the finished() signal to the model to "eliminate the intermediary handling of the reply" means that it will be handled by the manager as "intermediary".

                  Fair enough. I had interpreted "see/handle" as non-exclusive.
                  To me, a manager that inhibits what the model sees from a successful request is acting as part of the model. HTTP and QNetworkReply has error codes to indicate lack of success.

                  Asking a question about code? http://eel.is/iso-c++/testcase/

                  1 Reply Last reply
                  0
                  • T Offline
                    T Offline
                    TomZ
                    wrote on 4 May 2023, 20:18 last edited by TomZ 5 Apr 2023, 20:21
                    #16

                    Feels like the issue has little to do with the network request.

                    The issue is that the manager doesn't keep state.

                    So, if model X makes a request to the manager which is then forwarded to get an async reply. What you want to do is to ignore the fact on how its implemented and simply do what all async APIs do. Create a new QObject that emits a signal when its got a data update.

                    So what you see, as an example API, networkmanger::get() do, they return an object with a bunch of signals.

                    What you want to do is make you message-manager do the same. This means it needs to keep state. Which means it needs to route messages only back to the object it actually owns. An equivalent to the NetworkReply, maybe called SignalManagerReply...

                    The fact that the message-manager itself uses the network manager privately is a nice parallel you can probably use to mirror the workflows.

                    Edit; oh, and want to add that your initial statement of a 'model' asking he signal-manager something is breaking the model-view-controller design. You need a controller to handle an async API like the signalmanager would have (as a result of it using networkmanager).

                    Such a controller-style class is where the SignalManagerReply is used.

                    M 1 Reply Last reply 4 May 2023, 23:41
                    0
                    • T TomZ
                      4 May 2023, 20:18

                      Feels like the issue has little to do with the network request.

                      The issue is that the manager doesn't keep state.

                      So, if model X makes a request to the manager which is then forwarded to get an async reply. What you want to do is to ignore the fact on how its implemented and simply do what all async APIs do. Create a new QObject that emits a signal when its got a data update.

                      So what you see, as an example API, networkmanger::get() do, they return an object with a bunch of signals.

                      What you want to do is make you message-manager do the same. This means it needs to keep state. Which means it needs to route messages only back to the object it actually owns. An equivalent to the NetworkReply, maybe called SignalManagerReply...

                      The fact that the message-manager itself uses the network manager privately is a nice parallel you can probably use to mirror the workflows.

                      Edit; oh, and want to add that your initial statement of a 'model' asking he signal-manager something is breaking the model-view-controller design. You need a controller to handle an async API like the signalmanager would have (as a result of it using networkmanager).

                      Such a controller-style class is where the SignalManagerReply is used.

                      M Offline
                      M Offline
                      mzimmers
                      wrote on 4 May 2023, 23:41 last edited by
                      #17

                      @TomZ I ended up taking Jeremy's suggestion, and it works beautifully. Keeps the message manager self contained and no need for state awareness.

                      1 Reply Last reply
                      0
                      • M mzimmers has marked this topic as solved on 4 May 2023, 23:41

                      17/17

                      4 May 2023, 23:41

                      • Login

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