Op 28-8-2012 8:36, Till Oliver Knoll schreef: > Am 28.08.2012 um 04:10 schrieb Preet <prismatic.proj...@gmail.com>: > >> Hiya, >> >> 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. > > 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? > QFuture and QFutureWatcher are also designed for such tasks, but unfortunately it only works with the Qt Concurrent framework..
André _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
