>> I have a project where I'm trying to asynchronously reply to a signal. >> So if ObjectA sends ObjectB a signal, ObjectB will send ObjectA a >> reply signal at some later point in time. > > That sounds like "broken by design" to me: you'd have a dependency circle > here! In order to *connect* to a signal you have to *know* the signal > emiter's class. So signals should only go one way: bottom up.
Yeah, it's a little broken :) All the objects that are talking to each other in my scenario are actually plugins. I couldn't come up with a way to tell a potential plugin dev how to 'talk' to my ObjectB plugin without directly saying "give your plugin a slot called "onSomeSignal()" if you want me to talk to you!" > That said, your problem sounds a little bit what QNetworkAccessManager is > solving: you have multiple clients that request (by method call!) something > from the network, they get a handle (object) for the time being (with which > they can also e.g. abort the current operation), the QNAM does its work > asynchronously and finally emits a signal (actually several ones in each > state transition) once it's done (it doesn't know its clients though!). > > Why wouldn't that approach work in your case? I like this idea a lot... its a bit more work, but at least it'd let me adhere to the observer pattern. I'm gonna try and implement it, thanks for the idea! _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
