How to open a second form after a button is clicked in the first one?

[claudio-cit]

From the FAQ I read:

Assuming you have two form classes: Form1 and Form2 and that Form1 has a pushbutton "button" child and Form2 is derived from QDialog.

Add a custom slot to Form1 and fill it with:

void Form1::openForm2(){
static Form2 *form2 = new Form2(this);
form2->show();
form2->activateWindow(); // or form2->setActiveWindow() in Qt3
form2->raise();
}

If you want Form2 to be modal change it to:

void Form1::openForm2(){
Form2 form(this);
form2.exec();
}

Then you have to connect a proper signal to this slot. In the constructor of Form1 add:

connect(button, SIGNAL(clicked()), this, SLOT(openForm2()));

It's not clear yet, at least for me. I still have some questions:

1) The 2 Forms have to be in the same file?

2) Where I add the code? Into the .cpp or .ui or wherelse?

3) Could the 2nd Form be derived from QWindow or not?

[wysota]

Ad 1. - No
Ad 2. - Never touch the .ui, you add all code in a cpp file, as usual
Ad 3. - I don't know a class called QWindow, but the other form can be derived from any widget.

[claudio-cit]

Thank you wysota.

[claudio-cit]

How do the cpp file "knows" in which files are contained the 2 forms?

[jpn]

Originally Posted by claudio-cit

How do the cpp file "knows" in which files are contained the 2 forms?

Please learn at least basics of C++ before using Qt. Qt is not a programming language but an extensive C++ library. You need basic C++ knowledge to be able to use Qt. The FAQ answer would also be more clear if you understood C++...

[claudio-cit]

The problem is that i never used headers with classes when coding c++ at school. I know cpp, but I found almost nowhere how qt (and other libraries with classes) actually works..

I'm realizing now that:

- Qt designers produces an xml
- qmake get infos from xml and produces c++ code that put into header files
- the headers' code contains just classes definitions

So it's - now - obvious that in order to use Qt designer's code one have to:

- include the headers, #include "ui_header.h"
- edit default Qt Designer's objects' names in order to be able to distinguish classes (if one uses more than 1 form)

[wysota]

You had a course on C++ at school and you didn't write a single class during that course?

qmake get infos from xml and produces c++ code that put into header files

This is not true, qmake calls a special compiler (uic) that does that.

- the headers' code contains just classes definitions

This is not true either. Header file can contain implementation code as well. There might be no .cpp file or no .h file at all, it's just a useful convention to divide code into two files.

edit default Qt Designer's objects' names in order to be able to distinguish classes (if one uses more than 1 form)

This is not entirely true either. A side effect of setting the object name is that the resulting ui stub is called the same. But this is only a stub which you will use in a real widget class and the latter's class name is important.

[claudio-cit]

You had a course on C++ at school and you didn't write a single class during that course?

Sure i did. But i didn't know that libraries are kinda classes..

This is not true, qmake calls a special compiler (uic) that does that.

lol.....wtf! for me it's just a black box that do that. i just don't care - and i shouldn't - how does it works.

This is not true either. Header file can contain implementation code as well. There might be no .cpp file or no .h file at all, it's just a useful convention to divide code into two files.

i'm not talnking about .h in general. i'm talking about .h generated by qmake. ops.. by uic.

This is not entirely true either.

Entirely true? What is this, philosophy?!?!?

A side effect of setting the object name is that the resulting ui stub is called the same. But this is only a stub which you will use in a real widget class and the latter's class name is important.

I don't get what u mean. I have some questions to ask u about that last point:

Does it work an application if I have 2 forms (classes) differents, that do different things, that behave in a different way, composed by different objects, that are incorporated in the same .cpp? I'm pretty sure it doesn't.

If it does, how do you distinguish them?

If it does, is it safe coding in this way?

[JimDaniel]

Originally Posted by claudio-cit

lol.....wtf! for me it's just a black box that do that. i just don't care - and i shouldn't - how does it works.

The "Black Box" OOP metaphor doesn't refer or apply to to a programmer's understanding of his tools, that's the funniest thing I've read in awhile. Thanks! :-)

[claudio-cit]

Originally Posted by JimDaniel

The "Black Box" OOP metaphor doesn't refer or apply to to a programmer's understanding of his tools, that's the funniest thing I've read in awhile. Thanks! :-)

no comment

[wysota]

Originally Posted by claudio-cit

lol.....wtf! for me it's just a black box that do that. i just don't care - and i shouldn't - how does it works.

That kind of thinking got you into not knowing what is and is not a class, but ok, this is your choice. Unfortunately if at some point you'll be forced to use a different toolchain than qmake, you'll have to take a screwdriver, unscrew the black box and look what is inside.

i'm not talnking about .h in general. i'm talking about .h generated by qmake. ops.. by uic.

In that case you are wrong. Take a look at the file - it contains a lot of implementation code, actually most of it is the implementation

Entirely true? What is this, philosophy?!?!?

Fuzzy logic, I guess See the previous paragraph for an explanation or dig into the ui_xx.h file and see for yourself.

Does it work an application if I have 2 forms (classes) differents, that do different things, that behave in a different way, composed by different objects, that are incorporated in the same .cpp? I'm pretty sure it doesn't.

Yes, of course. You can implement the whole program in a single cpp file as long as your compiler can read large files. Actually if you take a look at this forum, you'll find lots of example applications that are contained in a single file most often called main.cpp.

If it does, how do you distinguish them?

I don't really understand this question...

If it does, is it safe coding in this way?

Yes, of course. Code readability and modularity is a different issue here, though.


A general remark - don't think of Qt as a separate language or some other special entity - it is just a set of classes written in standard C++, so all C++ rules apply to it. It's files are not in any way special apart from the fact that Qt introduces three new keywords to C++ but at the same time hides them from the C++ compiler, so that the only tool to see and understand them is moc (another part of the "qmake black box" that does most of Qt's "magic").