Solved Can a signal call a non-slot method
-
Hi,
Can a signal call an ordinary method in Qt/QML? I mean the ones apart from those declared under the
public/private slots
directive?
If so, then why do we need those directives? -
@tomy with the qt5 function pointer based syntax you can connect nearly anything to a Signal 😉
The slots marker is still needed for the old syntax, and it makes for a cleaner coding stile, as you see on one glance, what functions are supposed to be used with signals
-
Hi,
If you are thinking about the new Qt 5 signal/slot connection syntax, then no. The new syntax allows for compile time validation which you don't have with QML as it is an interpreted language.
In any case, these directives have several benefits:
- Keeps your classes compatible with the old syntax
- Makes your intention clear with regards to what is a slot and what is not
- Allows for introspection and meta-programming
-
Thank you for your answers.
Sorry, but to the extent I understood, @J-Hilk said yes, and @SGaist said no. :)
But I agree with both of you to have those directives.
I just was familiar with the new syntax:Old:
connect(sender, SIGNAL(valueChanged(QString, QString)), receiver, SLOT(updateValue(QString)));
New:
connect(sender, &Sender::valueChanged, receiver, &Receiver::updateValue);
Which one is more preferable, please? I'm using Qt 5.12.1.
The latter seems more fashionable! ;) -
You asked in the context of QML and it is in that context that I answered.
Otherwise, yes you can and the new syntax is preferred as it provides compile time diagnostic.
-
@SGaist
OK, got it thanks. So the answer is, for Qt it's fine but not in QML.
To sum up, I try to use the new style in Qt in addition to directives.
QML is quite different and I haven't seen the connection syntax used in Qt in it. All signals and slots apparently are built-in and we mostly only need to keep them in mind for use. -
To be more correct: the new syntax is for C++.
QML is JavaScript based, thus it's an interpreted language. The engine behind uses the Qt meta object system to connect all pieces.
You also have the Connection type which is somehow an equivalent to the QObject::connect method.
-
I get slightly confused by some of the comments here.
Let's be clear: under Qt5+, and for straight C++ not QML,
slots
is a macro and is defined as# define slots
So given that you can put in
slots
in your code (e.g.private slots
orpublic slots
) or you can omit it and it's not going to make any difference. Unless there's some magic to do with moc which I wouldn't know about. Not saying that it isn't a good idea to useslots
for your own clarity.And btw
# define signals public
so that's all that
signals
does.... (And by-the-by means that signals in one class can be called from any other class.)Finally, for completeness
# define emit
so that's all the signal/slot/emit "magic" :)
-
@JonB
well for pure Qt5 c++ code, you would be right.There's only one fringe case that I can think of. That would be the exception of the rule
bool QMetaObject::invokeMethod(QObject *context, Functor function, FunctorReturnType *ret)
which was introduced in 5.10 before that you had to use the string lookup variant that requires signal and slot macros.so that's all that signals does....
anything not defined as void would (here at least) seriously violate c++ norms!
-
Nothing Qt 5 specific, these macros have the same functionality since the beginning. They are used by moc to generate the adequate code.
With Qt 5, "slot" can be omitted as you have more freedoms for what you can connect to a signal. However, it's not just a question of "own clarity". If your public API is intended to be used as slot and you don't mark it as such, it will starts to be difficult for everybody (including yourself in six months) to understand how your code works.
-
Nothing Qt 5 specific, these macros have the same functionality since the beginning
Before Qt5
signals
wasprotected
, now it ispublic
(to allow new connection syntax). That was why I wrote Qt5+.And I did not intend to suggest one should omit
slots
. I should have said forowncode clarity, all I meant was the macro is actually empty so in the C++ sense you can omit it. -
@JonB said in Can a signal call a non-slot method:
Nothing Qt 5 specific, these macros have the same functionality since the beginning
Before Qt5
signals
wasprotected
, now it ispublic
(to allow new connection syntax). That was why I wrote Qt5+.Agreed
From my side, I was just talking about their purpose with regard to moc not their specific value.
-
You also have the Connection type which is somehow an equivalent to the QObject::connect method.
Thanks.
Why QObject::connect method explained in Docs under the name Qt 5.12.2 still uses the Qt 4 synatx version for connections, please?
I think the new Qt connection syntax version:
connect(sender, &Sender::valueChanged, receiver, &Receiver::updateValue);
is expressed merely in theory, and in practice, yet, it's the Qt 4's version which is used.
-
@tomy said in Can a signal call a non-slot method:
Why QObject::connect method explained in Docs under the name Qt 5.12.2 still uses the Qt 4 synatx version for connections, please?
because it's still valid.
The new syntax has it's own entry, further down:
https://doc.qt.io/qt-5/qobject.html#connect-3Both are overloads of the QObject::connect call -> both get an entry in the docs ;-)
-
@tomy If you want to use new Qt connection syntax, signal and slot must have same signature.
In your example, signal has 2 QString parameters and slot only 1.. This ist not allowed!
Which of signal parameter should be used for the slot?You can do someting like this using lambda function:
connect(sender, &Sender::valueChanged, receiver, [=](QString str1, QString) { receiver->updateValue(str1); });
Hope this helps.
ps: using "reciever" as context, so connection will be deleted with reciever is deleted. This will avoid null pointer exceptions.
-
@J.Hilk
Thanks Mr. Hilk. :-)@KroMignon
Thanks. :) -
And I guess it's not yet possible to using a simple way like below connect a signal to two slots in one statement:
connect(sender, &Sender::valueChanged, receiver, &Receiver::updateValue1, &Receiver::updateValue2 );
And we still have to use two lines:
connect(sender, &Sender::valueChanged, receiver, &Receiver::updateValue1); connect(sender, &Sender::valueChanged, receiver, &Receiver::updateValue2);
Right?
-
@tomy right
-
@tomy nope, you will have to use 2 lines
or a lambdaconnect(sender, &Sender::valueChanged, receiver, [receiver] (QVariant argument)->void{receiver->updateValue1(argument); receiver-> updateValue2(argument);});
-
Well, you can use a lambda and call each method one after the other.