Visual C++ doesn’t just compile code; it generates code. You can create a Windows application in minutes with a tool called AppWizard. In this Unit you’ll learn how to tell AppWizard to make you a starter app with all the Windows boilerplate code you want. AppWizard is a very effective tool. It copies into your application the code that almost all Windows applications require. After all, you aren’t the first programmer to need an application with resizable edges, minimize and maximize buttons, a File menu with Open, Close, Print Setup, Print, and Exit options, are you?
AppWizard can make many kinds of applications, but what most people want, at least at first, is an executable (.exe) program. Most people also want AppWizard to produce boilerplate code—the classes, objects, and functions that have to be in every program. To create a program like this, Choose File, New and click the Projects tab in the New dialog box, as shown in Figure 1.1.

FIG. 1.1 The Projects tab of the New dialog box is where you choose the kind of application you want to build.

Choose MFC AppWizard (EXE) from the list box on the left, fill in a project name, and click OK. AppWizard will work through a number of steps. At each step, you make a decision about what kind of application you want and then click Next. At any time, you can click Back to return to a previous decision, Cancel to abandon the whole process, Help for more details, or Finish to skip to the end and create the application without answering any more questions (not recommended before the last step). The following sections explain each step.

1.1.1 Deciding How Many Documents the Application Supports
The first decision to communicate to AppWizard, as shown in Figure 1.2, is whether your application should be MDI, SDI, or dialog based. AppWizard generates different code and classes for each of these application types.

FIG. 1.2 The first step in building a typical application with AppWizard is choosing the interface.
 

The three application types to choose from are as follows:
· A single document interface (SDI) application, such as Notepad, has only one document open at a time. When you choose File, Open, the currently open file is closed before the new one is opened.
· A multiple document interface (MDI) application, such as Excel or Word, can open many documents (typically files) at once. There is a Window menu and a Close item on the File menu. It’s a quirk of MFC that if you like multiple views on a single document, you must build an MDI application.
· A dialog-based application, such as the Character Map utility that comes with Windows.
As you change the radio button selection, the picture on the left of the screen changes to demonstrate how the application appears if you choose this type of application.
Beneath these choices is a checkbox for you to indicate whether you want support for the Document/View architecture. You should leave the option selected.
Lower on the screen is a drop-down box to select the language for your resources. If you have set your system language to anything other than the default, English[United States], make sure you set your resources to that language, too. If you don’t, you will encounter unexpected behavior from ClassWizard later. (Of course, if your application is for users who will have their language set to U.S. English, you might not have a choice. In that case, change your system language under Control Panel.) Click Next after you make your choices.

1.1.2 Databases
The second step in creating an executable Windows program with AppWizard is to choose the level of database support, as shown in Figure 1.3.

FIG. 1.3 The second step to building a typical application with AppWizard is to set the database options you will use.

There are four choices for database support:
· If you aren’t writing a database application, choose None.
· If you want to have access to a database but don’t want to derive your view from CFormView or have a Record menu, choose Header Files Only.
· If you want to derive your view from CFormView and have a Record menu but don’t need to serialize a document, choose Database View Without File Support. You can update database records with CRecordset, an MFC class.
· If you want to support databases as in the previous option but also need to save a document on disk (perhaps some user options), choose Database View With File Support.
If you choose to have a database view, you must specify a data source now. Click the Data Source button to set this up.
As you select different radio buttons, the picture on the left changes to show you the results of your choice. Click Next to move to the next step.

1.1.3 Compound Document Support
The third step in running AppWizard to create an executable Windows program is to decide on the amount of compound document support you want to include, as shown in Figure 1.4. OLE (object linking and embedding) has been officially renamed ActiveX to clarify the recent technology shifts, most of which are hidden from you by MFC. ActiveX and OLE technology are jointly referred to as compound document technology.

FIG. 1.4 The third step of building a typical application with AppWizard is to set the compound document support you will need.

There are five choices for compound document support:
· If you are not writing an ActiveX application, choose None.
· If you want your application to contain embedded or linked ActiveX objects, such as Word documents or Excel worksheets, choose Container.
· If you want your application to serve objects that can be embedded in other applications, but it never needs to run as a standalone application, choose Mini Server.
· If your application serves documents and also functions as a standalone application, choose Full Server.
· If you want your application to have the capability to contain objects from other applications and also to serve its objects to other applications, choose Both Container and Server.
If you choose to support compound documents, you can also support compound files. Compound files contain one or more ActiveX objects and are saved in a special way so that one of the objects can be changed without rewriting the whole file. This spares you a great deal of time. Use the radio buttons in the middle of this Step 3 dialog box to say Yes, Please, or No, Thank You to compound files.
If you want your application to surrender control to other applications through automation, check the Automation check box. If you want your application to use ActiveX controls, select the ActiveX Controls check box. Click Next to move to the next step.

1.1.4 Appearance and Other Options
The fourth step in running AppWizard to create an executable Windows program (see Figure 1.5) is to determine some of the interface appearance options for your application. This Step 4 dialog box contains a number of independent check boxes. Check them if you want a feature; leave them unchecked if you don’t.

FIG. 1.5 The fourth step of building a typical application with AppWizard is to set some interface options.

The following are the options that affect your interface’s appearance:
· Docking Toolbar. AppWizard sets up a toolbar for you. You can edit it to remove unwanted buttons or to add new ones linked to your own menu items.
· Initial Status Bar. AppWizard creates a status bar to display menu prompts and other messages. Later, you can write code to add indicators and other elements to this bar.
· Printing and Print Preview. Your application will have Print and Print Preview options on the File menu, and much of the code you need in order to implement printing will be generated by AppWizard.
· Context-Sensitive Help. Your Help menu will gain Index and Using Help options, and some of the code needed to implement Help will be provided by AppWizard. This decision is hard to change later because quite a lot of code is added in different places when implementing Context-Sensitive Help.
· 3D Controls. Your application will look like a typical Windows 95 application. If you don’t select this option, your dialog boxes will have a white background, and there will be no shadows around the edges of edit boxes, check boxes, and other controls.
· MAPI(Messaging API). Your application will be able to use the Messaging API to send fax, email, or other messages.
· Windows Sockets. Your application can access the Internet directly, using protocols like FTP and HTTP (the World Wide Web protocol). You can produce Internet programs without enabling socket support if you use the new winIet classes.
You can ask AppWizard to build applications with “traditional” toolbars, like those in Word or Visual C++ itself, or with toolbars like those in Internet Explorer.
You can also set how many files you want to appear on the recent file list for this application. Four is the standard number; change it only if you have good reason to do so.
Clicking the Advanced button at the bottom of this Step 4 dialog box brings up the Advanced Options dialog box, which has two tabs. The Document Template Strings tab is shown in Figure 1.6. AppWizard builds many names and prompts from the name of your application, and sometimes it needs to abbreviate your application name. Until you are familiar with the names AppWizard builds, you should check them on this Document Template Strings dialog box and adjust them, if necessary. You can also change the mainframe caption, which appears in the title bar of your application. The file extension, if you choose one, will be incorporated into filenames saved by your application and will restrict the files initially displayed when the user chooses File, Open.
The Window Styles tab is shown in Figure 1.7. Here you can change the appearance of your application quite dramatically. The first check box, Use Split Window, adds all the code needed to implement splitter windows like those in the code editor of Developer Studio. The remainder of the Window Styles dialog box sets the appearance of your main frame and, for an MDI application, of your MDI child frames. Frames hold windows; the system menu, title bar, minimize and maximize boxes, and window edges are all frame properties. The main frame holds your entire application. An MDI application has a number of MDI child frames—one for each document window, inside the main frame.

FIG. 1.6 The Document Template Strings tab of the Advanced Options dialog box lets you adjust the way names are abbreviated.

FIG. 1.7 The Window Styles tab of the Advanced Options dialog box lets you adjust the appearance of your windows.

Here are the properties you can set for frames:
· Thick Frame. The frame has a visibly thick edge and can be resized in the usual Windows way. Uncheck this to prevent resizing.
· Minimize Box. The frame has a minimize box in the top-right corner.
· Maximize Box. The frame has a maximize box in the top-right corner.
· System Menu. The frame has a system menu in the top-left corner.
· Minimized. The frame is minimized when the application starts. For SDI applications, this option will be ignored when the application is running under Windows 95.
· Maximized. The frame is maximized when the application starts. For SDI applications, this option will be ignored when the application is running under Windows 95.
When you have made your selections, click Close to return to step 4 and click Next to move on to the next step.

1.1.6 Other Options
The fifth step in running AppWizard to create an executable Windows program (see Figure 1.8) asks the leftover questions that are unrelated to menus, OLE, database access, or appearance. Do you want comments inserted in your code? You certainly do. That one is easy.

FIG. 1.8 The fifth step of building an application with AppWizard is to decide on comments and the MFC library.

The next question isn’t as straightforward. Do you want the MFC library as a shared DLL or statically linked? A DLL (dynamic link library) is a collection of functions used by many different applications. Using a DLL makes your programs smaller but makes the installation a little more complex. Have you ever moved an executable to another directory, or another computer, only to find it won’t run anymore because it’s missing DLLs? If you statically link the MFC library into your application, it is larger, but it is easier to move and copy around.
If your users are likely to be developers themselves and own at least one other application that uses the MFC DLL or aren’t intimidated by the need to install DLLs as well as the program itself, choose the shared DLL option. The smaller executable is convenient for all. If your users are not developers, choose the statically linked option. It reduces the technical support issues you have to face with inexperienced users. If you write a good install program, you can feel more confident about using shared DLLs.
After you’ve made your Step 5 choices, click Next to move to Step 6.

1.1.7 Filenames and Classnames
The final step in running AppWizard to create an executable Windows program is to confirm the classnames and the filenames that AppWizard creates for you, as shown in Figure 1.9. AppWizard uses the name of the project (FirstSDI in this example) to build the classnames and filenames. You should not need to change these names. If your application includes a view class, you can change the class from which it inherits; the default is CView, but many developers prefer to use another view, such as CScrollView or CEditView. The view classes are discussed in further Unit. Click Finish when this Step 6 dialog box is complete.

FIG. 1.9 The final step of building a typical application with AppWizard is to confirm filenames and classnames.

1.1.8 Creating the Application
After you click Finish, AppWizard shows you what is going to be created in a dialog box, similar to Figure 1.10. If anything here is wrong, click Cancel and work your way back through AppWizard with the Back buttons until you reach the dialog box you need to change. Move forward with Next, Finish; review this dialog box again; and click OK to actually create the application. This takes a few minutes, which is hardly surprising because hundreds of code lines, menus, dialog boxes, help text, and bitmaps are being generated for you in as many as 20 files. Let it work.

FIG. 1.10 When AppWizard is ready to build your application, you get one more chance to confirm everything.

1.1.9 Try It Yourself
Bring up AppWizard by choosing File, New and clicking the Projects tab. On the Projects tab, fill in a folder name where you would like to keep your applications; AppWizard will make a new folder for each project. Fill in FirstSDI for the project name; then move through the six AppWizard steps. Choose an SDI application at Step 1, and on all the other steps simply leave the selections as they are and click Next. When AppWizard has created the project, choose Build, Build from the Developer Studio menu to compile and link the code.
When the build is complete, choose Build, Execute. You have a real, working Windows application, shown in Figure 1.11. Play around with it a little: Resize it, minimize it, maximize it.

FIG. 1.11 Your first application looks like any full-fledged Windows application.

Try out the File menu by choosing File, Open; bring up the familiar Windows File Open dialog (though no matter what file you choose, nothing seems to happen); and then choose File, Exit to close the application. Execute the program again to continue exploring the capabilities that have been automatically generated for you. Move the mouse cursor over one of the toolbar buttons and pause; a ToolTip will appear, reminding you of the toolbar button’s purpose. Click the Open button to confirm that it is connected to the File Open command you chose earlier. Open the View menu and click Toolbar to hide the toolbar; then choose View Toolbar again to restore it. Do the same thing with the status bar. Choose Help, About, and you’ll see it even has an About box with its own name and the current year in the copyright date.
Repeat these steps to create an MDI application called FirstMDI. The creation process will differ only on Step 0, where you specify the project name, and Step 1, where you choose an MDI application. Accept the defaults on all the other steps, create the application, build it, and execute it.