Widget-Dialog communication

[hgedek]

I created a widget.It needs some informations from user.So I created a dialog too.And this dialog has treeWidget and items...(I thought to use ready dialogs.But they are specific )

So how can communicate widget with dialog?

[marcel]

You'll have to be more specific than that.
What exactly has the widget to communicate to the dialog( or the other way around)?
You could always use signals and slots, but it really depends on what you have to do.

Regards

[hgedek]

Only that:
Widget waits the name of selected tableWidgetItem which is listed in tableWidget on Dialog.
so I created both widget and dialog.dialog is a private member of widget class.
I couldnt understand that:
how can I call dialog and get the name?
dialog.exec( ) works?
Or?

[marcel]

Well, the easiest would be to emit a signal when you press the OK button in the dialog.
You can pass the the name of the item as parameter in the signal.
All that remains to do is to connect this signal to a slot in the widget. In this slot you will get the item name and you can use it.


Regards

[hgedek]

Ok.But the clicked() signal doesnt take any parameter.So how can I write a slot?
And I m calling dialog using dialog.exec();
When the widget called the dialog, does it wait the answer or the end of running of the dialog or doesnt?(I have no debug so I asked)

[marcel]

No, I meant creating a custom signal that you emit when you press the dialog.

But, if I get it correctly, you start the dialog from the widget.
Then why don't you wait until the user closes the dialog and just query it for the selected item? You could make a getter in the dialog that just returns a QString.

The data in the dialog won't be destroyed until the dialog itself is destroyed. Even if you hide it.

Regards

[jpn]

This is roughly how various QDialog subclasses like QFileDialog, QColorDialog and QFontDialog do it. The idea is to add a convenient static function that creates and executes the dialog with initial values set etc. If user cancels, a "null" value is returned, otherwise the actual value is returned:

class Dialog : public QDialog
{
public:
	Dialog(QWidget* parent = 0);
 
	static QString getValue(QWidget* parent = 0, 
								const QString& caption = QString(),
								const QString& value = QString());
private:
	QLineEdit* lineEdit;
};
 
Dialog::Dialog(QWidget* parent) : QDialog(parent)
{
	lineEdit = new QLineEdit(this);
	...
}
 
QString Dialog::getValue(QWidget* parent, const QString& caption, const QString& value)
{
	Dialog dialog(parent);
	dialog.setWindowTitle(caption);
	dialog.lineEdit->setText(value);
	if (dialog.exec() == QDialog::Accepted)
		return dialog.lineEdit->text(); // accepted, return actual value
	return QString(); // cancelled, return null string
}
 
// usage:
QString value = Dialog::getValue(parent, caption, initial);
if (!value.isNull())
{
	// accepted, do something with value
}

class Dialog : public QDialog
{
public:
	Dialog(QWidget* parent = 0);

	static QString getValue(QWidget* parent = 0, 
								const QString& caption = QString(),
								const QString& value = QString());
private:
	QLineEdit* lineEdit;
};

Dialog::Dialog(QWidget* parent) : QDialog(parent)
{
	lineEdit = new QLineEdit(this);
	...
}

QString Dialog::getValue(QWidget* parent, const QString& caption, const QString& value)
{
	Dialog dialog(parent);
	dialog.setWindowTitle(caption);
	dialog.lineEdit->setText(value);
	if (dialog.exec() == QDialog::Accepted)
		return dialog.lineEdit->text(); // accepted, return actual value
	return QString(); // cancelled, return null string
}

// usage:
QString value = Dialog::getValue(parent, caption, initial);
if (!value.isNull())
{
	// accepted, do something with value
}

To copy to clipboard, switch view to plain text mode 

Just notice that for a single textual/numerical input there is also QInputDialog readily available.

[awhite1159]

I have searched for best practices on returning values from dialogs for application use. This thread shows the basic concept. I would like to implement in a similiar fashion but have several values that need to be returned. Would returning a QList<QVariant> of the values be a good approach? Or are thier better ways that would take advantage of signals/slots etc. ?

[jpn]

I would like to implement in a similiar fashion but have several values that need to be returned. Would returning a QList<QVariant> of the values be a good approach? Or are thier better ways that would take advantage of signals/slots etc. ?

I would rather invent "a custom data type" which contains all necessary values and an isNull() method (to express cancelling). Qt makes it easy to get custom data types work seamlessly with QVariant, signals and slots, QDebug, QDataStream and QSettings...

[awhite1159]

Excellent. Thanks. I will try to implement it this way.