Qt: slot return value?

Question

According to the documentation, the return value from the slot means nothing.
However, in the generated moc code, I see that if the slot returns a value, that value is used for something. Any idea what he is doing?

---

Here is an example of what I'm talking about. this is taken from the code generated by moc. "message" is a slot that returns nothing, and "selectPart" is declared as returning an int.

case 7: message((*reinterpret_cast< const QString(*)>(_a[1])),(*reinterpret_cast< int(*)>(_a[2]))); break; case 8: { int _r = selectPart((*reinterpret_cast< AppObject*(*)>(_a[1])),(*reinterpret_cast< int(*)>(_a[2]))); if (_a[0]) *reinterpret_cast< int*>(_a[0]) = _r; } break; 

Answer 1

Looking through the Qt source, it seems that when a slot is called from QMetaObject :: invokeMethod, you can specify the return type and get the return value. (Look at invokeMethod in Qt help)

I could not find many examples of how this is really used in the Qt source. I found that

 bool QAbstractItemDelegate::helpEvent 

which is a return type slot and is called from

 QAbstractItemView::viewportEvent 

using invokeMethod.

I think that the return value for the slot is only available when the function is called directly (when it is a normal C ++ function) or when using invokeMethod. I think this is really intended for Qt's internal functions, and not for normal use in programs using Qt.

Edit: For example:

 case 8: { int _r = selectPart((*reinterpret_cast< AppObject*(*)>(_a[1])), *reinterpret_cast< int(*)>(_a[2]))); if (_a[0]) *reinterpret_cast< int*>(_a[0]) = _r; } break; 

vector _a is a list of arguments passed to qt_metacall. This is passed to QMetaObject :: invokeMethod. Thus, the return value in the generated moc code is saved and returned back to the caller. Therefore, for normal interactions with the signal-slot, the return value is not used at all. However, a mechanism exists, so that the return values ​​from the slots can be accessed if the slot is called through invokeMethod.

Answer 2

The return value is only useful if you want to call the slot as a regular member function:

 class MyClass : public QObject { Q_OBJECT public: MyClass(QObject* parent); void Something(); public Q_SLOTS: int Other(); }; 

void MyClass :: Something () {int res = this-> Other (); ...} Edit: It seems that this is not the only way to use the return value, the QMetaObject :: invokeMethod method can be used to call the slot and get the return value. Although it seems like it's a little harder to do.

Answer 3

Very useful when you are dealing with a dynamic language such as qtscript JavaScript QtPython and so on. With this language / bindings, you can use C ++ QObject dynamically using the interface provided by MetaObject. As you probably know, only signals and slots are analyzed using moc and generate a description of MetaObject. Therefore, if you use C ++ QObject from a javascript binding, you can only call slots and you need to return a value. Often Qt bindings for dynamic languages ​​provide some access to regular methods, but the process is definitely more of a trick.

Answer 4

All slots are displayed in QMetaObject, where the object can be accessed through the reflective interface.

For example, QMetaObject :: invokeMethod () takes a QGenericReturnArgument parameter. Therefore, I believe that this is not for the explicit use of slots, but for the dynamic invocation of methods in general. (There are other ways to expose methods in QMetaObject than by inserting them into slots.)

The invokeMethod function, for example, is used by various dynamic languages, such as QML and Javascript, to call QObject:s methods. (There is also a Python-Qt bridge called PythonQt that uses this. Not to be confused with PyQt , which is a complete shell.)

The return value is used when making synchronous calls on threads inside the Qt application (it is supported through invokeMethod and the connection type is set to Qt::BlockingQueuedConnection , which has the following documentation:

Same as QueuedConnection, with the exception of the current thread blocks, until the slot returns. This type of connection should only be used where the emitter and receiver are in different streams. Note. Violation of this rule may cause your application to deadlock.