Can a signal call a non-slot method

tomy

Hi,

Can a signal call an ordinary method in Qt/QML? I mean the ones apart from those declared under thepublic/private slotsdirective?
If so, then why do we need those directives?

J.Hilk

@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

SGaist

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

tomy

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! ;)

SGaist

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.

tomy

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

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.