Two class, two headers files - one problem.

[h-n-s]

#ifndef FORMCLASS1_H
#define FORMCLASS1_H
 
#include <QWidget>
#include "formclass2.h"
 
namespace Ui {
class FormClass1;
}
 
class FormClass1 : public QWidget
{
    Q_OBJECT
 
public:
    explicit FormClass1(QWidget *parent = 0);
    ~FormClass1();
 
    void test1(FormClass2 *ttee);
private:
    Ui::FormClass1 *ui;
};
 
#endif // FORMCLASS1_H

#ifndef FORMCLASS1_H
#define FORMCLASS1_H

#include <QWidget>
#include "formclass2.h"

namespace Ui {
class FormClass1;
}

class FormClass1 : public QWidget
{
    Q_OBJECT
    
public:
    explicit FormClass1(QWidget *parent = 0);
    ~FormClass1();
    
    void test1(FormClass2 *ttee);
private:
    Ui::FormClass1 *ui;
};

#endif // FORMCLASS1_H

To copy to clipboard, switch view to plain text mode 

#ifndef FORMCLASS2_H
#define FORMCLASS2_H
 
#include <QWidget>
 
#include "formclass1.h"
 
namespace Ui {
class FormClass2;
}
 
class FormClass2 : public QWidget
{
    Q_OBJECT
 
public:
    explicit FormClass2(QWidget *parent = 0);
    ~FormClass2();
 
 
    void test2(FormClass1 *test222);
 
private:
    Ui::FormClass2 *ui;
};
 
#endif // FORMCLASS2_H

#ifndef FORMCLASS2_H
#define FORMCLASS2_H

#include <QWidget>

#include "formclass1.h"

namespace Ui {
class FormClass2;
}

class FormClass2 : public QWidget
{
    Q_OBJECT
    
public:
    explicit FormClass2(QWidget *parent = 0);
    ~FormClass2();


    void test2(FormClass1 *test222);

private:
    Ui::FormClass2 *ui;
};

#endif // FORMCLASS2_H

To copy to clipboard, switch view to plain text mode 

Hi, I want to create a program that will consist of two classes.
I want to do something like this:
http://stackoverflow.com/questions/1...nother-class-c

but there is a problem:
/home/hans/QT_projects/Classtest/formclass2.h:21: błąd:'FormClass1' has not been declared


Please help me.

[ChiliPalmer]

You've got a cross-inclusion. Do it with forward declarations instead and put the includes in your cpp files:

#ifndef FORMCLASS1_H
#define FORMCLASS1_H
 
#include <QWidget>
 
namespace Ui {
class FormClass1;
}
 
class FormClass2;
 
class FormClass1 : public QWidget
{
    Q_OBJECT
 
public:
    explicit FormClass1(QWidget *parent = 0);
    ~FormClass1();
 
    void test1(FormClass2 *ttee);
private:
    Ui::FormClass1 *ui;
};
 
#endif // FORMCLASS1_H

#ifndef FORMCLASS1_H
#define FORMCLASS1_H

#include <QWidget>

namespace Ui {
class FormClass1;
}

class FormClass2;

class FormClass1 : public QWidget
{
    Q_OBJECT
    
public:
    explicit FormClass1(QWidget *parent = 0);
    ~FormClass1();
    
    void test1(FormClass2 *ttee);
private:
    Ui::FormClass1 *ui;
};

#endif // FORMCLASS1_H

To copy to clipboard, switch view to plain text mode 

#ifndef FORMCLASS2_H
#define FORMCLASS2_H
 
#include <QWidget>
 
namespace Ui {
class FormClass2;
}
 
class FormClass1;
 
class FormClass2 : public QWidget
{
    Q_OBJECT
 
public:
    explicit FormClass2(QWidget *parent = 0);
    ~FormClass2();
 
 
    void test2(FormClass1 *test222);
 
private:
    Ui::FormClass2 *ui;
};
 
#endif // FORMCLASS2_H

#ifndef FORMCLASS2_H
#define FORMCLASS2_H

#include <QWidget>

namespace Ui {
class FormClass2;
}

class FormClass1;

class FormClass2 : public QWidget
{
    Q_OBJECT
    
public:
    explicit FormClass2(QWidget *parent = 0);
    ~FormClass2();


    void test2(FormClass1 *test222);

private:
    Ui::FormClass2 *ui;
};

#endif // FORMCLASS2_H

To copy to clipboard, switch view to plain text mode 

[amleto]

If you have problem like this it usually points to a design problem. You should be able to refactor your code to remove circular references (I virtually guarantee that it's possible).

[d_stranz]

If you have problem like this it usually points to a design problem.

I sort of agree with this, but sometimes is really is necessary for two classes to know something about each other. But typically, the two classes don't actually need pointers to each other, what they need is to pass information between themselves. In Qt, this is usually done with signals and slots. Each class has a signal "sendSomeInformation( const SomeInfo & )" and a slot "receiveSomeInformation( const SomeInfo & )" which are cross-connected (in a way that doesn't cause infinite recursion). When Class1 changes the information, it emits the signal, which Class2 receives and can update its internal state accordingly. Likewise, the same thing happens when Class2 changes the state of the information. If there is more information that needs to be shared, either make a bigger (less granular) shared object or implement multiple signal / slot pairs.

Note that in this case, neither Class1 or Class2 know anything about the other, and don't need to; all they both know about is the "SomeInfo" class they pass back and forth. Likewise, the class that constructs the instances of Class1 and Class2 only needs to know that each of them has certain signals and slots that need to be connected, but that class doesn't need to know anything more about "SomeInfo" except that a reference will be passed in the connection.

The nice part about this from a design point of view is that you could completely replace Class1 or Class2 with a totally new implementation, and the opposite partner wouldn't know or care, so long as the signal, slot, and "SomeInfo" remained the same. The only class that would care is the one that constructs the two class instances.

[h-n-s]

I sort of agree with this, but sometimes is really is necessary for two classes to know something about each other. But typically, the two classes don't actually need pointers to each other, what they need is to pass information between themselves. In Qt, this is usually done with signals and slots. Each class has a signal "sendSomeInformation( const SomeInfo & )" and a slot "receiveSomeInformation( const SomeInfo & )" which are cross-connected (in a way that doesn't cause infinite recursion). When Class1 changes the information, it emits the signal, which Class2 receives and can update its internal state accordingly. Likewise, the same thing happens when Class2 changes the state of the information. If there is more information that needs to be shared, either make a bigger (less granular) shared object or implement multiple signal / slot pairs.

Note that in this case, neither Class1 or Class2 know anything about the other, and don't need to; all they both know about is the "SomeInfo" class they pass back and forth. Likewise, the class that constructs the instances of Class1 and Class2 only needs to know that each of them has certain signals and slots that need to be connected, but that class doesn't need to know anything more about "SomeInfo" except that a reference will be passed in the connection.

The nice part about this from a design point of view is that you could completely replace Class1 or Class2 with a totally new implementation, and the opposite partner wouldn't know or care, so long as the signal, slot, and "SomeInfo" remained the same. The only class that would care is the one that constructs the two class instances.

thx for msg.
I just solved this problem by using signals and slots mechanism.