Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

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 thepublic/private slotsdirective?
    If so, then why do we need those directives?


  • Moderators

    @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


  • Lifetime Qt Champion

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


  • Lifetime Qt Champion

    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.


  • Lifetime Qt Champion

    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 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" :)


  • Moderators

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


  • Lifetime Qt Champion

    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.



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


  • Lifetime Qt Champion

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



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


  • Moderators

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



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


  • Moderators

    @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);});
    

  • Lifetime Qt Champion

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



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


  • Moderators

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


  • Moderators

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


Log in to reply