Slot return value - what if it would be not lost?
-
I think what people try to explain is that decoupling the emitter and the receiver of a signal is a fundamental principle of Qt - and a good one - and this won't change, even you might have a use case for such a behaviour.
However, there are various programming techniques to circumvent this "limitation" - and most of them have been already posted here.
-
bq. I think what people try to explain is that decoupling the emitter and the receiver of a signal is a fundamental principle of Qt
"returning" value does not violate this principle - in spite of this principle we still can transmit parameters to receiver, but returned value does not differ from them... treat this as a "parameter" sent back from receiver to sender using same connection
-
[quote author="Gourmand" date="1310466527"]"returning" value does not violate this principle[/quote]
Yes, it does. The simple fact that your emitting object relies on the receiving object is the most obvious proof that there is no such decoupling in your application design.
[quote author="Gourmand" date="1310466527"]in spite of this principle we still can transmit parameters to receiver[/quote]
Yes, because passing parameters does not create dependencies between the emitter and the receiver ...
[quote author="Gourmand" date="1310466527"]but returned value does not differ from them... treat this as a "parameter" sent back from receiver to sender using same connection
[/quote]... while this will do.
Signals are defined as unidirectional connections to prevent dependencies of the emitting object to the receiving object. They are not functions nor methods. If you need the functionality of functions or methods you will need to use them.
-
You clearly have some issues understanding what others are telling you. And IMHO you are having a hard time understanding that passing a parameter to the receiver is not the same as passing a parameter back to the sender (the most obvious part being that there might be more than one receiver).
And frankly your ignorance of what people are trying to tell you is starting to get annoying. If you really think that you are smarter then all of us put together, than you really should be able to patch Qt with your required functionality and use it!
-
bq. Yes, it does. The simple fact that your emitting object relies on the receiving object
No. It does not. It does not rely more than it already relies because of parameters type must match.
bq. because passing parameters does not create dependencies between the emitter and the receiver
But it creates!!... you cannot connect methods with different parameters types and number, that means receiver already depends from sender and vise versa
Returning value does not create more dependencies than already exist... There are only some incomprehensibilities with returned value from several slots or if returned type does not match expected - but this can be worked around.
bq. passing a parameter to the receiver is not the same as passing a parameter back to the sender
Not exactly the same, but it could be implemented under cover looking as the same to be more useful
bq. you really should be able to patch Qt
no-no... all of this would be better implemented by Qt-developers, they know internals much better than me
-
sigh...
Let's agree that Qt currently does not support your use case, it won't in the near future and that you will have to create such a mechanism on your own.
And let's agree that if you feel the urgent need that the Qt developers should do that work for you you are free to file a feature request to the bugtracking system and see what time will bring.