Solved Can a signal call a non-slot method
-
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.
-
Thanks to all.
@J.HilkI used this:
connect(someAction, &QAction::triggered, this, [this]()->void { this->slot_1(); this->close(); });
The return type of
slot_1
isvoid
but that forclose()
isbool
, but since the return value of a slot is ignored when it's called by a signal in connections, so I also usedvoid
for the lambda expression above. -
@tomy seems about right.
You could technically omit the return type here, but proper form (strongly) suggest that you write one ;-) -
@J.Hilk
You mean this "->void
" part?
And that's once again because it's within a connection, right? -
@tomy said in Can a signal call a non-slot method:
You mean this "->void" part?
yes
And that's once again because it's within a connection, right?
no, the compiler can and will deduce the return type. However if you write
-> void { return true;}
you'll get a compile time warning/compiler error.