Le 16/01/2017 à 10:34, Olivier Goffart a écrit :
What's the use case for this function? For direct call you better of calling
the function directly, and the equivalent of QueuedConnection can be achieved
with QTimer::singleShot.
Hi.
AFAIK there is no other way to call a method across threads *and wait
for it result* than QMetaObject::invokeMethod() with
Qt::BlockingQueuedConnection and Q_RETURN_ARG (apart, of course, making
the called method thread-safe).
I would personally be happy if (like Benjamin proposes) there were some
compile time check, IDE symbols following/renaming and no longer need to
declare such methods as Q_INVOKABLE (or slot).
Therefore IMO methods pointers would be great in
QMetaObject::invokeMethod() as they are in QObject::connect(). :-)
And maybe lambdas too, if there was a way to choose the thread/eventloop
in which we want the lambda to be executed (but christmas was a few
weeks ago, I should not dream ;-)).
Also (I still dream), if there was a way to make invokeMethod()
automagically choose between a direct call and
Qt::BlockingQueuedConnection, it would be possible to get rid of this idiom:
if (QThread::currentThread() == this->thread())
foo = func();
else
QMetaObject::invokeMethod(this, "func",
Qt::BlockingQueuedConnection,
Q_RETURN_ARG(foo));
Kind of Qt::DirectOrBlockingQueuedConnection.
--
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
