The really important MFC classes have to do with providing a Document-View architecture. Some of the most important of these classes are the CWinApp, the CDocument, the CView, and the CDC.
When you're running a program, there will be one CWinApp object, and this is the program itself. The CWinApp is responsible for things like routing the program messages, organizing the windows, and deciding what order to do things in. Later, when we want to make our programs do things like move images around even when there's no user input, it will be the CWinApp that does this for us.
In a particular program like Pop, your application is a CPopApp object. CPopApp is a class derived from CWinApp. It's defined in the Pop.* files.
When you're looking at a window, there are three ways of thinking of it. First of all, behind the scenes, there's a CDocument object in which you can store the data that the window displays. Second, the window itself is a CView (which is a specialized version of a general window class called a CWnd ). Third, when you want to send graphics output to your window, you think of it as a CDC, where the 'DC' stands for 'Device Context.'
The CView contains the operating system's ID for keeping track of one window as opposed to another. The Windows operating systems uses the CView as a way of keeping track of which particular window is supposed to process a given message, such as a menu selection or a mouse-click.
A CDC is used whenever you want to write any text or graphics to the window. A window's CDC has information about the window's current location and appearance on the screen. As you resize the window, move it around, and possibly change its color palette, the appearance of the window will change, so usually you need to get a fresh CDC for the window right before you do a graphics call. Graphics functions such as TextOut and Ellipse are members of the CDC class.
Why does Windows have to make it so hard for us? Why do we have to have a CWinApp, CView s, and CDC s? Well, many programs have the ability to open up a number of different windows, so it stands to reason that, although there is only one CWinApp, your program may well have different CView. But, why must the CDC differ from the CView ?
Well, it turns out that you can have a CDC which is not associated with an onscreen window. When you send text or graphics to your printer, you get a CDC for the printer, which is not a window at all. And we'll also find that we can have CDC s which contain invisible memory bitmaps rather than being actual windows. These 'virtual window' CDC s are essential for writing programs that have moving objects on the screen. The way Windows usually does animation is to prepare each new frame of the animation offscreen in a memory-based virtual window CDC, and then, once the new frame is ready, to use the rapid BitBlt operation to copy the image to the CDC of the visible onscreen CView.
As well as the CWinApp, CView, and CDC classes, there are MFC classes which represent graphics tools called pens, brushes, bitmaps, and more. These classes have names like CPen, CBrush, and CBitmap.
Take a look at the header files for some of the AppWizard-generated classes like CPopDoc as defined in popdoc.h and CPopView as defined in popview.h. Note that these machine-generated files are very messy-looking. It's a good practice to put all the things that you add down at the end of the class declarations so they're easy for you to find. In general the order in which things appear within a class declaration doesn't matter, so we put the human-written stuff at the bottom so it's easy to find. Generally, it's only the human-written code that you want to edit anyway. It's also a good idea to set off the human-written code with a comment line.
If you keep your code at the very bottom of the class it will be easy for you and other programmers to find. Although you can use the Class View to add variables, it is easier and safer to type in your variables by hand. There's no telling where Class View will put the variables inside the class. If you type them in by hand you can insist on keeping them all at the bottom of the class definition. By the way, it doesn't matter where any block of code appears inside a class definition.