Can a signal call a non-slot method

[SGaist]

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.

[JonB]

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 or public 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 use slots 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" :)

[J.Hilk]

@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!

[SGaist]

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.

[JonB]

@SGaist

Nothing Qt 5 specific, these macros have the same functionality since the beginning

Before Qt5 signals was protected, now it is public (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 for own code clarity, all I meant was the macro is actually empty so in the C++ sense you can omit it.

[SGaist]

@JonB said in Can a signal call a non-slot method:

@SGaist

Nothing Qt 5 specific, these macros have the same functionality since the beginning

Before Qt5 signals was protected, now it is public (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.

[tomy]

@SGaist

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.

[J.Hilk]

@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-3

Both are overloads of the QObject::connect call -> both get an entry in the docs ;-)

[KroMignon]

@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.

[tomy]

@J.Hilk
Thanks Mr. Hilk. :-)

@KroMignon
Thanks. :)

[tomy]

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?

[KroMignon]

@tomy right

[J.Hilk]

@tomy nope, you will have to use 2 lines
or a lambda

connect(sender, &Sender::valueChanged, receiver, [receiver] (QVariant argument)->void{receiver->updateValue1(argument); receiver-> updateValue2(argument);});

[SGaist]

Well, you can use a lambda and call each method one after the other.

[tomy]

Thanks to all.
@J.Hilk

I used this:

connect(someAction, &QAction::triggered, this, [this]()->void
               { this->slot_1(); this->close(); });

The return type of slot_1 is void but that for close() is bool, but since the return value of a slot is ignored when it's called by a signal in connections, so I also used void for the lambda expression above.

[J.Hilk]

@tomy seems about right.
You could technically omit the return type here, but proper form (strongly) suggest that you write one ;-)

[tomy]

@J.Hilk
You mean this "->void" part?
And that's once again because it's within a connection, right?

[J.Hilk]

@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.