Exercises

Exercise 23.1: Checking the CRect and CString documentation

Look up the documentation on CRect , CSize , CString , and CPoint . We're going to be using these classes from time to time. Be sure and get an idea of the different methods and constructors that these classes have.

Exercise 23.2: Checking the WinMain documentation

Look up WinMain in the Visual Studio Help and see what it says about WinMain in MFC.

Exercise 23.3: Using the debugger to look under the hood of MFC

How does one find out how the CPopView::CView constructor gets called from inside CPopApp::InitInstance ? As a way of getting to know the debugger, let's work through some steps to figure it out.

First put a breakpoint inside the (empty brackets) code for the constructor in the CView.cpp file. Place the breakpoint by right-clicking at the spot where you want it and selecting Insert/Remove Breakpoint from the context menu. Then select Build Start Debug Go to run the program in the debugger until it hits the breakpoint. If the program stops too early, press F5 to make it run all the way to the breakpoint. Now select View Debug Windows Call Stack to see what functions were recently called. The window shows the most recent call at the top, the call before that one step down, and so on. Do any of these functions look familiar? Hmm, maybe not. This seems to be kind of a false start. Interesting, though, all those function calls. Do remember to use the Call Stack dialog later when your programs start crashing, and you want to try and step backwards from a given bug.

So now try something different to figure out how that constructor gets called. Put a breakpoint at the if (!ProcessShellCommand(cmdInfo)) line in CPopApp::InitInstance . Use the Debug Restart selection to start over, press F5 if the debugger stops too soon, and when you get to the breakpoint, use the Debug Step Into (or the F11 shortcut key for this, or the Step Into button on the Debug toolbar). You'll find yourself in a switch statement, and if you press F11 some more, you'll see you go into the case CCommandLineInfo::FileNew: of the switch. Aha! But why does the case value have that odd name ? It turns out it's an enum value associated with the CCommandLineInfo class. To confirm this, place your cursor inside m_nShellCommand and press F1 for the help file information.

If you want to step further on, you may want to use the F10 or Debug Step Over to avoid going into each function call.

Gnarly, huh? The moral is that you can get lots of information out of MFC and the Developer's Studio, but you have to feel around a bit to find it. There's so much more information than you can absorb , you need to be pretty quick and casual in the process “ while remaining determined and implacable at the same time.

Exercise 23.4: Checking the message handling documentation

Look up the Help on the CWnd::OnSysCommand message handler. Aren't you glad you don't have to take care of all these situations yourself? The base class automatically handles these. For most messages, you will in fact be using the base class window behavior. And any message that doesn't happen to be handled either by your special CView or by the base class CWnd gets sent to a default message processing function. This default processor is the CWnd::DefWindowProc method. Look this method up in the Help.

Exercise 23.5: Changing the caption bar and the About dialog

Put your own name in the caption bar of Pop and in the About dialog box.

Exercise 23.6: Editing the icons

Change the appearance of the Pop 1 IDR_MAINFRAME icons. Be sure to change both sizes. Once you've opened the icon in the Visual Studio's Resource Editor, you can switch sizes with the Device: combo box, which has two options Standard (32 x 32) and Small (16 x 16) . Figure out how to get these icons to appear in Windows Explorer and/or on your desktop.

Exercise 23.7: Changing the file extension

Try changing the file extension and file name for your version of Pop.