Example of Static QDialog

[sa5webber]

I'm looking for simple examples of a dialog box form implementation where a user fills out the form and then after the form dialog box exits the calling routine can still call static methods on the dialog box to access the filled out data.

In other words unless somebody has a better idea I think I'm looking for an example of a static dialog box implementation with static methods and members. My current approach based upon other GUI implementations is not working.

[wysota]

Do you use the word "static" in the meaning C++ defines that term? If not, please define what you mean.

[sa5webber]

Yes. I mean static as in it gets allocated when the program starts and remains for the life of the program so that irregardless of whether the dialog box is open or closed the contained static variables retain their last set state.

Actually I meant upon the declaration of the dialog box, not the beginning of the program.

[wysota]

Yes. I mean static as in it gets allocated when the program starts and remains for the life of the program so that irregardless of whether the dialog box is open or closed the contained static variables retain their last set state.

This has nothing to do with "static methods" then. You mean a static object and you can't have that since you can't allocate any widgets before QApplication object is created. I don't even know why you'd want such thing.

You can call static methods on objects related to Qt exactly the same way you can call static methods on objects unrelated to Qt (apart the limitation I mentioned).

[ChrisW67]

Yes. I mean static as in it gets allocated when the program starts and remains for the life of the program so that irregardless of whether the dialog box is open or closed the contained static variables retain their last set state.

Actually I meant upon the declaration of the dialog box, not the beginning of the program.

No, I don't think you mean "static" in any C++ sense at all. The C++ object and its possible visual presence are not related to each other. The member variables in the object do not go away when the visual item is hidden: they only go away when you destroy the object. Here's an example of a dialog that is shown, hidden, and shown again. The value of its text box persists between showings and is available when the dialog is hidden:

#include <QtGui>
 
class MyDialog: public QDialog
{
    Q_OBJECT
public:
    explicit MyDialog(QWidget *p = 0): QDialog(p) {
        QVBoxLayout *layout = new QVBoxLayout(this);
        lineEdit = new QLineEdit(this);
        QPushButton *button = new QPushButton("Ok", this);
        layout->addWidget(lineEdit);
        layout->addWidget(button);
        setLayout(layout);
 
        connect(button, SIGNAL(clicked()), SLOT(accept()));
    }
 
    QString getText() const {
        return lineEdit->text();
    }
private:
    QLineEdit *lineEdit;
};
 
 
int main(int argc, char **argv) 
{
    QApplication app(argc, argv);
 
    MyDialog dialog; // dialog object exists
    (void) dialog.exec();    // dialog is visible
    qDebug() << dialog.getText();    // dialog is not visible but the object still exists
    (void) dialog.exec();    // dialog is visible
    qDebug() << dialog.getText();    // dialog is not visible but the object still exists
 
    return 0;
}
#include "main.moc"

#include <QtGui>

class MyDialog: public QDialog
{
    Q_OBJECT
public:
    explicit MyDialog(QWidget *p = 0): QDialog(p) {
        QVBoxLayout *layout = new QVBoxLayout(this);
        lineEdit = new QLineEdit(this);
        QPushButton *button = new QPushButton("Ok", this);
        layout->addWidget(lineEdit);
        layout->addWidget(button);
        setLayout(layout);

        connect(button, SIGNAL(clicked()), SLOT(accept()));
    }

    QString getText() const {
        return lineEdit->text();
    }
private:
    QLineEdit *lineEdit;
};


int main(int argc, char **argv) 
{
    QApplication app(argc, argv);

    MyDialog dialog; // dialog object exists
    (void) dialog.exec();    // dialog is visible
    qDebug() << dialog.getText();    // dialog is not visible but the object still exists
    (void) dialog.exec();    // dialog is visible
    qDebug() << dialog.getText();    // dialog is not visible but the object still exists

    return 0;
}
#include "main.moc"

To copy to clipboard, switch view to plain text mode 

[sa5webber]

Good explanation. Thanks for the clarification. What you showed is exactly what I want. I need to be able to potentially open and close the form multiple times. It wasn't clear to me what exec() and closing the form actually did to the object in memory and so I was initially deleting the object myself on closure and re-creating it to open it again to avoid any potential memory leak which is why I was asking about the static approach.

So with that said. I found this link yesterday.

http://www.qtcentre.org/threads/7315...le-QFileDialog

It looks like it uses a static method to declare MyDialog and show the dialog. It appears the difference between what you're showing and what it does is that it uses MyDialog directly to open the dialog without having to declare it externally. Although I have a question as to the MyDialog declaration in the static method. Is this declaration also assumed to be static since its in a static method so that the declaration only occurs the first time the method is called?

In your opinion is there any advantage/disadvantage to either way?

By the way thanks again for all your expertise and help.

---

Added after 20 minutes:

I should clarify that the code in the link I 'm referring to is in reply #5.

[ChrisW67]

The static function creates a local instance of the MyDialog class which is automatically destroyed at the end of the function. The MyDialog instance is not static just because it is created inside a static function.

A static convenience function in a class like this dialog is usually used as a way to create a quick, short-lived instance with common defaults that returns a simple value of some sort, e.g. QFileDialog or QInputDialog.

With QWidgets like QDialog just make sure you give the object a parent at creation on the heap and don't worry about the memory deallocation: it will be freed when the parent is.