I just started to fool around with QT4. I was wondering how experienced
organized the widgets used in GUI's.

For instance if I were to use several widget objects in a particular program, is it better practice to make a header file for each function?

If I wanted a spin box function that selected tools, should I isolate that off in tool.h ?

This sounds like a good idea for clarity and updating, but i want to be sure...

I don't want to learn bad habits.

Unless you are writing c++ templates don't put executable class implementation code in *.h files -- it goes in *.cpp file.

Perhaps I'm fuzzy on this...
I thought that *.cpp files had to have main() and there can be only ONE main per application.
Implementation code will get compiled as executable if included in the
main.cpp like #include "tool.h", won't it??

Otherwise I am quite confused on the the uses of *.cpp and *.hpp file extentions.

Are you saying that individual custom GUI classes CAN"T be -or shouldn't be spun off into external files at all?

*.cpp files may, not required to contain main(). A program can be comprised of many, if not hundreds, of *.cpp file(s). GUI programs written for MS-Windows do not have a main() at all -- instead they have a WinMain().

When you write a c++ console program, it can contain as many *.cpp files as you want it to have. But only one, and only one, of them can contain a main() function. Actually, that isn't completly accurate either because the main() can be in a *.c (a C program unit, not c++). Many programs consist of both *.c and *.cpp files.

Header files normally (except c++ templates) consist of only c++ classes, structures and defines because they can be included in all the *.c and *.cpp files within the project(s). The implementation code is normally contained in *.c and *.cpp files.

>>Are you saying that individual custom GUI classes CAN"T be -or shouldn't be spun off into external files at all?
Not sure what you mean by that. GUI classes, just like all other c++ classes, declarations should be in *.h files and implementation code in *.cpp file. Many companies require that a *.cpp and *.h file is limited to only one c++ class and correcponsing *.cpp implentation file. So if the program consists of two unrelated c++ classes then each would be in its own *.cpp and *.h file. The *.cpp files are conpiled separately and linked together at link time along with other libraries.

OK, so those are the "usages" . I now have better idea of what goes where.

Now getting back to that custom GUI class "tool" using something like QT4.

If I wanted to separate it into it's own file I would...:

1) put all declarations (functions, public, private, etc)
into a tool.h

2) put the class's definitions into a tool.cpp file.

3) in the main.cpp (where main() or winmain() lives) I can call
the member functions of tool by just doing an #include "tool.h
and the compiler looks for the tool.cpp automatically?

Also, is it OK to have "nested includes"?
For instance, in class definition tool.cpp there would be an include for <QTwidget> among others which would pulled in through
#include "tool.h" into main.cpp.(I think)

It makes good sense that "some companies" require one class
per file, especially in a huge project. How else would you be able to find what you're looking for other than having to resort to grep (or something like it)?

I have noticed that the codeblocks ide sets up all projects with the core program file named main.cpp (with main() in it.)
I suppose if you have a ton of *.cpp files, it make the core file stand out. Now that you have told me that multiple *.cpp
files are possible, this makes allot of sense now.

Sometimes i "think into" things too much and get twisted up like this...

>>I can call the member functions of tool by just doing an #include "tool.h and the compiler looks for the tool.cpp automatically?

No -- you have to have a project that contains both main.cpp and tool.cpp. Your compiler will compile them separately then link the object files together along with other libraries to creat the final program. There is nothing "automatic" about it. Depending on what compiler you use you have to tell it what *.cpp, object files and libraries to include in the program.


>>How else would you be able to find what you're looking for other than having to resort to grep (or something like it
Some compilers (like Microsoft's) have a browse utility that show you what classes and associated methods are included in the project and contain links to files where they are located. Just clikc on the link and the compiler's IDE will move the cursor direcly to the object. Really great programming tool

Thanks for the info...

I still am unclear on the syntax for pulling everything together.

assumptions:
1) gcc compiler
2) I have created a custom gui class called tool
3)I have a project directory with main.cpp, tool.h and tool.cpp in it.
4) I am going to push the 'build" button.

How do I get to use tool member functions in main.cpp?
Do I need to include both? ie;

If this concept were expanded, the main.cpp could conceivably consist of little more than includes and function calls-right?

I was also wondering about the logic behind separating the declarations and definitions into two different files. Is this also to reduce "clutter" ?