setup my own abstract class functions.. (about connect and slots)

[jeremy_k]

https://doc.qt.io/qt-5/qobject.html#connect:

QMetaObject::Connection QObject::connect(
    const QObject *sender, 
    const char *signal,
    const QObject *receiver,
    const char *method,
    Qt::ConnectionType type = Qt::AutoConnection
);

[JonB]

@U7Development
Maybe now is the time to move over from your SIGNAL/SLOT() macros to New Signal Slot Syntax ?

[Christian Ehrlicher]

@JonB said in setup my own abstract class functions.. (about connect and slots):

Maybe now is the time to move over from your SIGNAL/SLOT() macros to New Signal Slot Syntax ?

But this makes it even harder for him because then it's a PMF which has to be passed to the function. And as you can see there are currently problems passing a simple const char * ... :)

[JonB]

@Christian-Ehrlicher
I don't care! It's a function pointer. If you & he want to keep working on managing your slot connections via an untyped, unparsed arbitrary string that's up to you :) In this forum I have seen people pass an utterly rubbish string for the SLOT() (or SIGNAL()) parameter, and then wonder why it doesn't work... I'm surprised at you! ;-)

[Poor English]

@JonB
After reading your advice on the problem，I checked the new usage of the signal slot you mentioned on the Internet and tried to learn it，then I used 【connect(btn,&QPushButton::XXX, xx, &XXX::XXX)】this from replaced the previous【SIGNAL】usage，and the program is still robust as before。Although I don't know the working principle of the signal slot and the specific differences between the two，the new usage is more convenient from the writing point of view，so I will follow the guidance you provide and try to use 【&】not【SIGNAL】，thank you！

[mrjj]

@Poor-English

Hi
The main difference between the old and new syntax is runtime lookup of the given slot/signal name versus
compile-time verification of the given class method pointer.

the SIGNAL and SLOTS macros will accept any string at compile-time and first fail at runtime

The "new" & syntax is evaluated at compile-time and is type-safe, meaning
it will complain about missing signals or slot or even parameter mismatch.

Poster could do like

(in .h)
class MainWindow;
using CALL = void (MainWindow::*)(void); // function pointer to (named)  class memeber
(in .cpp) 

QPushButton *MainWindow::setup_button(QString _txt, QString _style, QRect _geo, CALL _param)
{
    QPushButton *o = new QPushButton(_txt);
    o->setStyleSheet(_style);
    o->setGeometry(_geo);
    connect(o, &QPushButton::clicked, this, _param);
    return o;
}

using:
  auto b = setup_button( "Test", "", QRect(0, 10, 100, 100), &MainWindow::DoSomething );

To use new syntax, BUT this case is easy as he wants to use just clicked()
With another type of widgets and with different parameters, it becomes quite the template show.

[Poor English]

@mrjj
Oh yeah。。。thank you！！
you have deepened my understanding of the new usage of signal slot，finding errors at compile time is better than finding errors at runtime！it seens it is time to say goodbye with【SIGNAL】。。。I meet Qt from a book，in that book，it used all 【SIGNAL】，now it seems that the book should be quite old。

[mrjj]

@Poor-English
Yes for bigger apps and more than one developer, catching type errors and at compile time has a huge benefit
as the app might have not so often used dialogs and some parameter change in other part of the app might silently fail
with the MACROS and first be discovered at end users.
With the new syntax, the first developer to recompile will see it.
That said, connect with MACROS does return true or false so its possible to catch connect failures, making
it less of a burden.

But the new syntax also offers new features, such as lambdas )in place, nameless function) and those can be very handy
for keep together compact code. So yes, you will not really look back once getting used to the new syntax.

[U7Development]

I have tried const char pointer with no success but i guess i was in a mistake using connect argument

const chart _param* used as:

connect(btn, SIGNAL(clicked()), this, SLOT(_param));

now i will change to :

connect(btn, SIGNAL(clicked()), this, _param);

Regarding to new connect parameter format, its time to check it out.
Thanks!

[JonB]

@U7Development
Yes, to match your

connect(o, SIGNAL(clicked()), this, _param);

you wanted to know what UnknownParam _param should be in setup_button() definition, and that should indeed be const char *_param to do things this way. The caller will pass SLOT(whatever), you won't use SLOT() in your code in your setup_button() code here.