If you haven't done so yet, use Windows Explorer to find the Pop code, and click on the pop.sln file to start up Visual Studio if you are using Visual Studio.NET [or the pop.dsw file if you are using Version 6.0].
Note that Appendix C summarizes information about specific Visual Studio controls in Visual Studio.NET, Version 7.0, and Visual Studio, Version 6.0.
You'll see several windows inside the Visual Studio window, as illustrated in the screenshot. The largest window is a Document window for showing your code. There will eventually be tabs along the top of this window with one tab corresponding to each code file that you have open. We'll refer to a horizontal (or vertical) bar upon which tabs rest as a tab group.
The new Visual Studio.NET
There will probably be an Output window near the bottom, where you can view such things as compiler and linker messages. If this window isn't immediately present, it will appear once you build your code. Or you can open it with View | Other Windows | Output Window.
Other windows may also appear near the bottom of the screen. And there will be a tab-select bar along the bottom of the screen with tabs in order to keep track of which of these windows is currently 'on top.'
There may also be a number of windows along the right- or left-hand side of the main window. The View menu will open up more of them.
The multiple windows along the edges are attached to vertical tab groups, one on the left and one on the right.
The tabs on the vertical tab groups shrink to button size when their associated window is not the active window. You can change the active window on a vertical tab group by moving your mouse over the buttons on the tab group.
On the horizontal tab groups at the bottom and top of the screen, you select a window by clicking on its tab rather than simply moving the mouse over the tab.
Each of the windows along the sides and bottom of the Visual Studio.NET interface has a 'pushpin' button that you can use to either make the window stay open (pin pointing down) or to have the window only appear when you move the mouse over the window's tab in the toolbar (pin pointing sideways). The document viewing windows don't have the pushpin feature.
One special window you generally want to have open is the Solution Explorer, which makes it possible to easily access your code and to change the project settings. Use View | Solution Explorer in order to open this window so we can investigate some of the files in the Pop framework.
[You'll see two or maybe three windows inside the Visual Studio window. On the upper left will be the Workspace window, on the upper right will be a Document pane where you can view help files or source-code files, and on the bottom there may be an Output window where you can view such things as compiler and linker messages. You can also open and close these two windows by using the View | Workspace and View | Output menu selections.
The Workspace and Output windows are usually 'docking' windows, meaning that they stay stuck to the sides of your main window. (Windows that aren't docked are called 'floating.')
The Workspace window has three tabs at the bottom, so you can select the Class View, the File View, or the Info View. The first shows the structure of the classes used in your project, the second shows the files, and the third shows a list of the Microsoft help books currently available to you.
Click on the File View tab of the Workspace window so that we can investigate some of the files in the Pop Framework.]
The tried and true Visual Studio, Version 6.0
There will be one or several toolbars at the top of the Visual Studio window. Sometimes Visual Studio may open up more toolbars than you want, thus eating up too much of your screen area, so you may want to close some of them down. You can control which toolbars are visible by right-clicking in the toolbar area and checking or unchecking various boxes.
Suppose now that you are looking at the Solution Explorer window in Visual Studio.NET [or at the File View of the Workspace (Version 6.0)].
Whenever you see an entry with a plus sign next to it, that means you can click it to see more. You'll see source files, header files, resource files and some free-standing *.wav sound files.
Look into the source and header files folders. Whoah! There's so many of them! How are you ever going to learn to use MFC and the Pop Framework?
Stay calm. Don't panic. In order to build on other people's code you need to be comfortable with a certain level of ignorance. You need to accept that the Pop Framework has given you this big stack of files and you may never get around to looking at all of them. This is a typical situation when you go to work at a company with an established code base. In the case of the Pop Framework, most of the files don't directly impinge on your near-term goal of building your own computer game project.
To get a quick overview of what the files are like, try double-clicking on a few of them. This opens them up in a text-editor in the document window, and you can scroll through them. One file worth looking at is ReadMe.txt, which has some short descriptions about what the special MFC files are all about. But at this point these short descriptions won't make much sense to you.
Sometimes you need to have *.obj or *.lib files as part of a project, for instance to support OpenGL or to support sound. We don't include these files in the File View. Instead we select the project and use the View | Property Pages... | Linker | Input | Additional Dependencies line [this is the Project | Settings... | Link | Object/Library Modules box in Version 6.0.]
One bad feature of the File View that you see in Solution Explorer [or in the File View of the Workspace pane (Version 6.0)] Studio Workspace window is that it doesn't state the directories where the files listed live. This can be dangerous if you have several versions of a file with the same name, as you can easily include a file from the wrong directory.
In Visual Studio.NET, you can check the directory for a file by highlighting it and using View | Properties Window to look at the Full Path field. Note that you don't want to use View | Property Pages to view the Full Path; the similarly named Properties Window and Property Pages are different dialogs.
[In Version 6.0, there is only one kind of Properties dialog for a file and it has a File Name field that shows the path. You can open this dialog by right-clicking the file and selecting Properties from the little menu that appears, or by pressing Alt+Enter. Note that in Visual Studio.NET, these actions will open Property Pages but not Properties.]
Once you've taken a look at some of the files which come with the Pop Framework, use the Build | Build Pop.exe selection to build Pop.exe. As the file builds you'll see a few messages down in the bottom of the screen in the Output pane that look something like the following. Depending on the processor speed of your machine and, more importantly, on how rapidly your machine can write intermediate files to its hard drive, the full build might take anywhere between a few seconds or several minutes.
Here's a copy of the output generated a while back, by building Pop version 21.
------------------Configuration: Pop ? Win32 Debug------------------ Compiling resources... Compiling... StdAfx.cpp Compiling... biota.cpp ChildFrm.cpp colorstyle.cpp [Lots more file names come here...] Compiling... VectorTransformation.cpp Generating Code... Linking... Pop 21(Debug Build).exe ? 0 error(s), 0 warning(s)
Yay! 0 errors, 0 warnings is what you want to see.
If this doesn't work for you, look at the Correcting Compiler and Linker Errors subsection 20.5 below. If this does work for you, use the Build | Execute Pop.exe selection to get the program to run.