Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Troubles with QPushButton::clicked
In Qt Designer, I created on the same way 2 flat QPushButtons in a widget (FYI a "duplicate" and a "remove" button).
Both have similar caracteristics (here are the ones for the right "remove" button):
From the menu "Go to slots ...", I created a clicked() slot method for every one
private slots: ... void on_duplicateButton_clicked(); void on_removeButton_clicked();
At runtime, clicking on the left button ("duplicate" button) is working fine. But clicking on the right button ("remove" button) does not call the slot method. Graphically, one can see that the button is correctly clicked (and is then on front of the UI).
Any attempt to replace the "clicked" slot with another one (pressed or released) did not succeed.
What have I done wrong ? Any help is welcome.
To be noted : according to the selection in a tree widget, those buttons are set visible or not. Could this be the reason of any problem ?
Qt Creator 4.7.1 on Windows 10
Qt 5.11.2 (MSVC 2015, 32bit)
the remove button MUST be called "removeButton" exactly for it to work so that's first check.
Its very convenient with the auto clot creation and connection but sadly it also breaks very easy.
So i must recommend for real applications, to use
manual connect statements using the new syntax
This will give an error on compile time if not working.
Many thanks for those info.
I created the manual connection in the main window
connect( ui->removeButton, &QPushButton::clicked, this, &MainWindow::on_removeButton_clicked );
and it works :-) .
Does it mean that it is not recommended to use the Signals/Slots editor from Qt Designer ?
In the caracteristics panel of Qt Designer, the button is well called "removeButton". Hence in this case, is this really the reason ?
Many thanks again.
well, the Signal and slot editor work via a naming convention
so if either the slot or widget is renamed, it's not connected anymore. ( silently)
So it breaks very easy even if very nice to use.
So for a one-man project, it might not be that bad to use but for
bigger projects it's not optimal.
So yes, for the compile-time errors and not silent fail at runtime, it's very recommended
Im not sure if the name was the case for not working.
anyway, it simply works from Qt calling
which looks for on_WidgetName_Signal
so if it find a match it connects for you.
OK. Thanks for the advice. It's added in my coding rules ;-)
The manual connection solved my issue.