Unsolved Avoiding circular dependency with signals/slots
-
Two ways:
1, same signals are sent to all nodes. These signals, however, have embedded Node id info in them. Parse them and ignore the signals which are not related. Simple protocol thing.
2. send different signals to different nodes.
I will go with the first one. -
@JoeCFD 1. is what I proposed in the question, but worried that it would be inefficient.
Not sure how 2. would work as the "Nodes" are generated dynamically, unless there's also a way to dynamically create signals? Thanks -
@ECEC Parsing is very fast in GUI design. No worry about the efficiency. It is good enough to do it with unique ids or object names.
-
@ECEC said in Avoiding circular dependency with signals/slots:
@SGaist Thanks for your response. Could you elaborate please? I'm not sure how QNetworkAccessManager might solve my problem.
I meant from an architecture point of view.
With QNAM you can either connect your QNAM directly and manage things with it concerning the replies or you use the QNetworkReply returned by the operation you want to execute and use its signals and slots.
-
@SGaist Could you please illustrate with an example in the context of my application? Not sure I'm understanding how implementing something similar would work in practice.
-
Your ProtocolManager could return something similar to a reply that could then be connected by the Node to a lambda or a slot to do further processing of the answer.
Therefor, your ProtocolManager would not have to care about the Node objects.
-
@SGaist Ahhh, I think I see what you mean. So when the Nodes make a command request to the ProtocolManager, it returns a pointer to some sort of Reply object which the ProtocolManager populates when data for that Node is available. The Reply object then emits a signal which connects to a slot in Node. As requests are made frequently (10/sec) and the responses are short, I wonder whether it might make sense to have just one Reply object per Node instead of generating a new one per command request. What do you think, and is the above what you had in mind? Cheers
-
Yes that's that.
I would first get it to work and then benchmark the simple implementation. If you see performance issue then start optimizing.
-
@SGaist As the responses are so short, is there a risk that data is received and the Reply signal is emitted before the Reply object has been returned to the Node and connected? Is there a way to prevent this from happening?
-
If you queue the request, it should not.
As already suggested, you should take a look at the implementation of QNAM. You make a request, get a reply object and there's no "speed" issue with it.