Whether to use signals/slots, or a function call from MainWindow added to a project to display QString return value from function in other Widget

[DavidEdwards]

I am using the QWidget from an existing project I found at https://github.com/confidentFeng/QtAppProject/tree/master/WifiList

In a Qt Widgets Application I have added a QLabel, and a QPushButton on the MainWindow which opens an instance of the WifiList widget from the github project.

My goal is to display in a QLabel (or QLineEdit or similar text-displaying object) the QString return value from QString WifiList::getConectedWifi(), line 105 in WifiList.cpp.

On another post, Access an existing class and use QDialog::accept in a connect() to pass a QString value param?, a suggestion is: "The usual way of getting, say, a string back from a dialog it invokes does not involve any signal/slot. Instead the dialog should expose a getter."

My question are signals and slots required, or recommended, to do this, or can the WifiList::getConectedWifi() function be called from the mainwindow to display the QString value on the QLabel in the main window (as in the below mock-up):

QString values from qDebug() in the output

[Axel Spoerl]

@DavidEdwards said in Whether to use signals/slots, or a function call from MainWindow added to a project to display QString return value from function in other Widget:

are signals and slots required, or recommended, to do this or can the WifiList::getConectedWifi() function be called from the mainwindow to display the QString value on the QLabel in the main window (as in the below mock-up):

If WifiList lives in the same thread as MainWindow. you can call the getter directly. If it lives in a different thread, you have to invoke it. That solution works in a safe pull-environment. In other words:

• It can safely be assumed that the getter is called on a valid object
• MainWindow controls when it fetches the string to display

In a push-environment, where the label / line edit has to be automatically updated if the connected WiFi changes, signals and slots are the right implementation. You would have to implement a connectedWifiChanged(const QString &wifi) signal in WifiListand connect it to the label's / line edit's setText(const QString &text) slot. Besides the automatic update, the advantage is that the MainWindow doesn't have to know if WifiList is still alive. If it's destroyed, the connection is disconnected as well.

[Pl45m4]

@DavidEdwards

Hi and welcome to the forum!

First thing I've noticed: your widget does not have any layout... for testing it's okay, but later you should add a proper layout strategy otherwise you will face unwanted behavior on resizing or moving your window around.

Regarding your inital question:
As always, the answer is "it depends"...
Both ways are possible, but one fits a certain situation more than another.

My question are signals and slots required, or recommended, to do this, or can the WifiList::getConectedWifi() function be called from the mainwindow to display the QString value on the QLabel in the main window (as in the below mock-up):

No they are not required, not in this situation.

When your dialog finishes with accepted status, you can use the function(s) to retrieve the data you want to use.

However @JonB 's suggestion involves QDialog::exec() which is not recommended (anymore), according to its documentation.
If you know what you are doing there's still nothing wrong with it.
(Documentation is refering to a situation where the parent might be destroyed while the dialog's event loop is running, which shouldn't happen, when used correctly)

The alternative, showing your dialog with QDialog::open() is asynchronous.
Means, no own event loop, not blocking the code execution of the parent.
Therefore you can't tell when you are safe to call your getters...
Using Qt Signals can solve this... either by connecting the accepted signal to a slot or by using a lambda expression.

[DavidEdwards]

Hi and thank you for your warm welcome @Pl45m4 !

Thank you @Axel-Spoerl and @Pl45m4 for your detailed insights and sharing your expertise.

Your explanations helped me to best understand my options and the requirement for my chosen implementation.

I intend to have push-environment. Once getting the signal / slot implemented correctly on the appropriate components, and understanding the object who knows where the signal should go should do the connections - it worked.

@Pl45m4 and @Axel-Spoerl thank you very much for your assistance and through explanations!