Send Signals to a specified receiver
-
Hello,
is it possible to send an signal to a specified receiver if multiple receiver are connected? How does the syntax look like then?
An alternative will be to create multiple functions and use 1:1 connections.
I am new to qt and have no idea what design would be better (or even possible)
thanks
-
[quote author="peppe" date="1326278431"]This is totally breaking the whole concept of signals and slots. If you have to communicate something to a specific object, simply invoke a method on it.[/quote]
Thanks for the answer.
I am thinking of a configuration class which can do following thinks:
1)Receive a configuration for a module which is stored in a map<key,map<string,string>>
key = modulename for configuration
map<string,string> = config and value pair- On request signal from a (specific module) for a value the config class looks if this value is set in the xml config file. If so then it send the required value to the (specific module) if not then the default value is set.
Multiple methods would cause a specialisation like
@
void sendToTerminal( ... )
void sendToEditor( ... )
@and i would to keep the class abstract as possible to be able to use it in any program i write.
Maybe i should public inherit from the abstract config class to specialise it and put then the methods inside?
-
As peppe already states sending a signal only to a specific slot is in contradiction to the signal-slot concept of Qt. However, you may include in the slot parameter list a parameter allowing the receiving object to decide whether it shall process or not.
-
[quote author="koahnig" date="1326279715"]However, you may include in the slot parameter list a parameter allowing the receiving object to decide whether it shall process or not.
[/quote]Thanks for the reply
I already thought about such solution but that will cause a lot of overhead ... i am still thinking of any better design idea.
The inheritance will work but i will still be dependent to include the header file from the config ... i want to have a separate compilation of the dynamic libs to be possible.
-
When overhead is your concern than basically you can call the methods directly in the different objects as suggested by Peppe.
With signals and slots you can send different signals which are relayed to the different objects because you can decide with connect where to send. However, this is at the day's end not much different from direct calls when the signals are processed syncronously. -
Some random ideas:
- Add a QString parameter to signal in which you store the module name (key for the outer map)
- In the class that creates the modules, use a [[Doc:QSignalMapper]] to distinguish the senders
How do you send back the data?
Why is that requestConfig() signal connected to multiple receivers at all and not only to your single config provider class?
-
This is totally breaking the whole concept of signals and slots. If you have to communicate something to a specific object, simply invoke a method on it.
Well, depends on what one is using the S&S for. E.g., I am using the mechanism mostly for lockless inter-thread communication, so I can't simply invoke the method on the object operating in another thread. In my specific case, I have a one-to-many blocking signal/slot mapping, with a returning data. I.e. passing a parameter to the slot to allow it not to react isn't an solution, as I would only get the data from the last-invoked slot. I can temporarily disconnect all the objects which are not intended as signal's recipients and then reconnect them, but this is ugly. I.e, an optional parameter to the emit function to specify the object to emit to would be cheap to implement and useful for me (and I suppose for the original post's author).
So instead, I am invoking the slot directly through QMetaObject::invokeMethod
-
Well, depends on what one is using the S&S for. E.g., I am using the mechanism mostly for lockless inter-thread communication, so I can't simply invoke the method on the object operating in another thread. In my specific case, I have a one-to-many blocking signal/slot mapping, with a returning data. I.e. passing a parameter to the slot to allow it not to react isn't an solution, as I would only get the data from the last-invoked slot. I can temporarily disconnect all the objects which are not intended as signal's recipients and then reconnect them, but this is ugly. I.e, an optional parameter to the emit function to specify the object to emit to would be cheap to implement and useful for me (and I suppose for the original post's author).
So instead, I am invoking the slot directly through QMetaObject::invokeMethod
@Maxim-Adelman
Hello,So instead, I am invoking the slot directly through QMetaObject::invokeMethod
Then you don't need the function to be a slot at all. You can just mark it known to the meta-object system with
Q_INVOKABLE. The point is however that the slot shouldn't care to know who exactly emitted the signal, this is the idea behind decoupling of the components.PS.
This thread is quite old (an understatement I know), so I'm doubtful of the gain in resurrecting it.Kind regards.
