How can I access public variable parent Form

[validator]

Hi, I have a form and there is a pushbutton on the form. When I click the pushbutton , I open new Form by name sampleForm. How can I access public variable of parent class from sampleForm.

[marcel]

Many ways...
1) Pass it to the child form, in the constructor.
2) Make a setter method in the child form and set the variable after you instantiate the form
3) Access it directly from the parent form, like this ((ParentForm*)parent())->yourPublicVar. But this is very ugly, since you would have to include the ParentForm here just for that.

I recommend 1 or 2.

[aurelius]

When I include the header file of the parent form, it throws me an error, that the current class is not declared in the parent form. What I mean is:

I have the parent form

#include "childForm.h"

class parentForm
{
...
childForm ch ;
} ;

and the child form

#include "parentForm.h"

class childForm
{
...
} ;

When I add #include "parentForm.h", then it says that it doesn't recognize the childForm type in the declaration of the parentForm. Obviously there is a confilct. Do you know some way to overcome it ?

[spirit]

use forward declaration insted of including headers, i.e.


...
class childForm;

class parentForm
{
...
childForm *ch ;
} ;
...

[aurelius]

I have already tried this. The thing is, that I create a Form with QtDesigner, which is the parent class. Inside the form I put a class of my own, that inherits QWidget and this is the child form. If i do forward declaration, it says that I use functions that I have not implemented. I think this happens, because QtDesigner puts all the code inside the header file. I will try it again though, but I don't think it is sufficient. Any other ideas ?

[spirit]

could you prepare compilable example and show it?

[aurelius]

I attach a folder with 3 files, the parent header from QtDesigner and the child.

[aurelius]

The parent class is Ui_Form and the child class is paintimagewidget. I changed the names of the files. The original for the parent was ui_manysift.h and for the child paintimagewidget

[spirit]

there are two ways to set up ui
1.


//h-file
#include "ui_manysift.h"

class PaintImageWidget : public QWidget, private Ui::Form
{
Q_OBJECT
....
};

//cpp-file
PaintImageWidget::PaintImageWidget(QWidget *parent)
: QWidget(parent)
{
setupUi(this);
}

2.


//h-file
#include "ui_manysift.h"

class PaintImageWidget : public QWidget
{
Q_OBJECT
....
private:
Ui::Form m_ui;
};

//cpp-file
PaintImageWidget::PaintImageWidget(QWidget *parent)
: QWidget(parent)
{
m_ui.setupUi(this);
}

PS. this is not compilable example, I can't do qmake && nmake.

[aurelius]

I had a mistake in forward declaration. I found it, so now it works :). Thanx for the help anyway ...

[rexi]

there are two ways to set up ui

I always wondered, is there a preferred way to do it? What are the advantages or disadvantages of either approach?

[spirit]

if modify second approch you can get more perfomance on compilation stage, i.e. if ui-file has been modified then only needed cpp file will be rebuild. this approach is very usefull in big project with many ui-files.


//h-file
#include <QWidget>

namespace Ui {
class MyWidget;
};

class MyWidget: public QWidget
{
Q_OBJECT

public:
MyWidget(QWidget *parent = 0);
virtual ~MyWidget();

private:
Ui::MyWidget *m_ui;
};

//cpp-file
#include "mywidget.h"
#include "ui_mywidget.h"

MyWidget::MyWidget(QWidget *parent)
: QWidget(parent)
{
m_ui = new Ui::MyWidget;
m_ui->setupUi(this);
}

MyWidget::~MyWidget()
{
delete m_ui;
m_ui = 0;
}

[rexi]

So, in general there is no real advantage in any of the two first approaches, except that it's probably easiser to modify the second one to the third that you posted?

The third approach looks very interesting, I guess it can save quite some compile time while developing an application.

[spirit]

Yes:) the third one is usefull when you have a lot of ui files

[rexi]

I see that :) I always wondered what the difference between the first two ones was, but it just seems to be a matter of taste ;) Thanks for clarifying that, and for pointing out the third one. I have to keep that one in mind, it might come in handy some day ;)