Connecting to Q_INVOKABLE as a slot?
-
I am using Qt4.8 (in the form of BlackBerry Cascades on BlackBerry 10 OS). Somebody posted a question in one of the Cascades Dev Support forums that is really more about Qt itself. Without going into into details about the original question, what came out of that discussion is this... why is it possible to connect a Q_INVOKABLE class function to a signal as if it is a slot?
I know that the opposite is perfectly valid, this is to say that any class method declared with Q_SLOT is automatically also Q_INVOKABLE, but my understanding is that only functions declared with Q_SLOT should be connectible. To be more specific, Cascades has a class called NavigationPane, which has a Q_INVOKABLE method called pop(). I have checked, and not only does the Cascades documentation say this function is Q_INVOKABLE, not Q_SLOT, but an inspection of the relevant header file confirms it, so this is not just a documentation error. Somebody in the forum commented that they were connecting this method to a signal, and it was WORKING. The Momentics IDE was complaining that pop() was not declared as a slot, but it was compiling and pop() was being triggered by the signal as if it really was a slot. When challenged on this usage, the poster pointed to a code snippet in the Cascades documentation that does precisely the same thing, which started a debate about how this could possibly be working.
Since MOC handles Q_INVOKABLE and Q_SLOT rather than expanding them as macros I haven't been able to figure out what the difference is. I can confirm that the MOC produces identical intermediate C++ for a class method regardless of whether it is declared with Q_INVOKABLE or Q_SLOT.
I should point out that pop() takes no arguments, so perhaps Q_SLOT tells the compiler something about connecting up parameters between signals and slots and so this only works when there are none. In any case, I am very surprised that this works at all, and I wonder if any of the experts here have any insight into what is going on?
-
Hi and welcome to devnet,
I'd advise to ask this interesting question on the interest mailing list, you'll find there Qt's developers/maintainers (this forum is more user oriented) Don't forget to first subscribe before posting on the mailing list.
-
Hi, there is no magic here
@
connect(a, SIGNAL(sig()), b, METHOD(mtd()));
connect(a, SIGNAL(sig()), b, SLOT(slt()));
connect(a, SIGNAL(sig()), b, SIGNAL(sig2()));
@equal to
@
connect(a, "2sig()", b, "0mtd()");
connect(a, "2sig()", b, "1slt()");
connect(a, "2sig()", b, "2sig2()");
@ -
Yes, as I said, both Q_INVOKABLE and Q_SLOT generate exactly the same intermediate C++, so I would expect the SIGNAL() and SLOT() macros to expand the way you show, but that explains nothing about the difference between declaring a method as Q_INVOKABLE or as a Q_SLOT. So far, all the evidence you or I have presented paints either declaration as identical, but I doubt this is actually true. If Q_INVOKABLE and Q_SLOT are equivalent, why would Qt have both of them and why are we told to use Q_SLOT for signal handlers?
The real question here is how do the two declarations actually differ, and why does it work when you connect a signal to a Q_INVOKABLE method even though we are supposed to use the Q_SLOT declaration for signal handlers?
-
Hi, maybe this is helpful for you http://qt-project.org/forums/viewthread/570
-
Actually, I have already seen that post. Unfortunately I don't think it answers my question, other than to note that class constructors can be Q_INVOKABLE but not Q_SLOTs. If that is the ONLY difference then in almost every case the two can be used interchangeably, and yet I have never seen any Qt documentation that suggests that you shouldn't always be using Q_SLOT for signal handlers. If true then Q_SLOT becomes redundant and is an unnecessary element of Qt that should probably be eliminated. I am really doubtful that Q_INVOKABLE and Q_SLOT don't have inherent differences, tiny ones though they may be.
-
"Here":http://lists.qt-project.org/mailman/listinfo/interest is the list