C++- Programming Microsoft Visual C++.doc

- 673 -copyright 1998 by david j. kruglinski chapter one 1. microsoft windows and visual c+enough has already been written about the acceptance of microsoft windows and the benefits of the graphical user interface (gui). this chapter summarizes the windows programming model (win32 in particular) and shows you how the microsoft visual c+ components work together to help you write applications for windows. along the way, you might learn some new things about windows. 2. the windows programming modelno matter which development tools you use, programming for windows is different from old-style batch-oriented or transaction-oriented programming. to get started, you need to know some windows fundamentals. as a frame of reference, well use the well-known ms-dos programming model. even if you dont currently program for plain ms-dos, youre probably familiar with it. 2.1 message processingwhen you write an ms-dos-based application in c, the only absolute requirement is a function named main. the operating system calls main when the user runs the program, and from that point on, you can use any programming structure you want. if your program needs to get user keystrokes or otherwise use operating system services, it calls an appropriate function, such as getchar, or perhaps uses a character-based windowing library. when the windows operating system launches a program, it calls the programs winmain function. somewhere your application must have winmain, which performs some specific tasks. its most important task is creating the applications main window, which must have its own code to process messages that windows sends it. an essential difference between a program written for ms-dos and a program written for windows is that an ms-dos-based program calls the operating system to get user input, but a windows-based program processes user input via messages from the operating system. many development environments for windows, including microsoft visual c+ version 6.0 with the microsoft foundation class (mfc) library version 6.0, simplify programming by hiding the winmain function and structuring the message-handling process. when you use the mfc library, you need not write a winmain function but it is essential that you understand the link between the operating system and your programs. most messages in windows are strictly defined and apply to all programs. for example, a wm_create message is sent when a window is being created, a wm_lbuttondown message is sent when the user presses the left mouse button, a wm_char message is sent when the user types a character, and a wm_close message is sent when the user closes a window. all messages have two 32-bit parameters that convey information such as cursor coordinates, key code, and so forth. windows sends wm_command messages to the appropriate window in response to user menu choices, dialog button clicks, and so on. command message parameters vary depending on the windows menu layout. you can define your own messages, which your program can send to any window on the desktop. these user-defined messages actually make c+ look a little like smalltalk. dont worry yet about how these messages are connected to your code. thats the job of the application framework. be aware, though, that the windows message processing requirement imposes a lot of structure on your program. dont try to force your windows programs to look like your old ms-dos programs. study the examples in this book, and then be prepared to start fresh. 2.2 the windows graphics device interfacemany ms-dos programs wrote directly to the video memory and the printer port. the disadvantage of this technique was the need to supply driver software for every video board and every printer model. windows introduced a layer of abstraction called the graphics device interface (gdi). windows provides the video and printer drivers, so your program doesnt need to know the type of video board and printer attached to the system. instead of addressing the hardware, your program calls gdi functions that reference a data structure called a device context. windows maps the device context structure to a physical device and issues the appropriate input/output instructions. the gdi is almost as fast as direct video access, and it allows different applications written for windows to share the display. 2.3 resource-based programmingto do data-driven programming in ms-dos, you must either code the data as initialization constants or provide separate data files for your program to read. when you program for windows, you store data in a resource file using a number of established formats. the linker combines this binary resource file with the c+ compilers output to generate an executable program. resource files can include bitmaps, icons, menu definitions, dialog box layouts, and strings. they can even include custom resource formats that you define. you use a text editor to edit a program, but you generally use wysiwyg (what you see is what you get) tools to edit resources. if youre laying out a dialog box, for example, you select elements (buttons, list boxes, and so forth) from an array of icons called a control palette, and you position and size the elements with the mouse. microsoft visual c+ 6.0 has graphics resource editors for all standard resource formats. 2.4 memory managementwith each new version of windows, memory management gets easier. if youve heard horror stories about locking memory handles, thunks, and burgermasters, dont worry. thats all in the past. today you simply allocate the memory you need, and windows takes care of the details. chapter 10 describes current memory management techniques for win32, including virtual memory and memory-mapped files. 2.5 dynamic link librariesin the ms-dos environment, all of a programs object modules are statically linked during the build process. windows allows dynamic linking, which means that specially constructed libraries can be loaded and linked at runtime. multiple applications can share dynamic link libraries (dlls), which saves memory and disk space. dynamic linking increases program modularity because you can compile and test dlls separately. designers originally created dlls for use with the c language, and c+ has added some complications. the mfc developers succeeded in combining all the application framework classes into a few ready-built dlls. this means that you can statically or dynamically link the application framework classes into your application. in addition, you can create your own extension dlls that build on the mfc dlls. chapter 22 includes information about creating mfc extension dlls and regular dlls. 2.6 the win32 application programming interfaceearly windows programmers wrote applications in c for the win16 application programming interface (api). today, if you want to write 32-bit applications, you must use the new win32 api, either directly or indirectly. most win16 functions have win32 equivalents, but many of the parameters are different16-bit parameters are often replaced with 32-bit parameters, for example. the win32 api offers many new functions, including functions for disk i/o, which was formerly handled by ms-dos calls. with the 16-bit versions of visual c+, mfc programmers were largely insulated from these api differences because they wrote to the mfc standard, which was designed to work with either win16 or win32 underneath. 3. the visual c+ componentsmicrosoft visual c+ is two complete windows application development systems in one product. if you so choose, you can develop c-language windows programs using only the win32 api. c-language win32 programming is described in charles petzolds book programming windows 95 (microsoft press, 1996). you can use many visual c+ tools, including the resource editors, to make low-level win32 programming easier. visual c+ also includes the activex template library (atl), which you can use to develop activex controls for the internet. atl programming is neither win32 c-language programming nor mfc programming, and its complex enough to deserve its own book. this book is not about c-language win32 programming or atl programming (although chapter 29 and chapter 30 provide an introduction to atl). its about c+ programming within the mfc library application framework thats part of visual c+. youll be using the c+ classes documented in the microsoft visual c+ mfc library reference (microsoft press, 1997), and youll also be using application framework-specific visual c+ tools such as appwizard and classwizard. use of the mfc library programming interface doesnt cut you off from the win32 functions. in fact, youll almost always need some direct win32 calls in your mfc library programs. a quick run-through of the visual c+ components will help you get your bearings before you zero in on the application framework. figure 1-1 shows an overview of the visual c+ application build process. figure 1-1. the visual c+ application build process. 3.1 microsoft visual c+ 6.0 and the build processvisual studio 6.0 is a suite of developer tools that includes visual c+ 6.0. the visual c+ ide is shared by several tools including microsoft visual j+. the ide has come a long way from the original visual workbench, which was based on quickc for windows. docking windows, configurable toolbars, plus a customizable editor that runs macros, are now part of visual studio. the online help system (now integrated with the msdn library viewer) works like a web browser. figure 1-2 shows visual c+ 6.0 in action. figure 1-2. visual c+ 6.0 windows. if youve used earlier versions of visual c+ or another vendors ide, you already understand how visual c+ 6.0 operates. but if youre new to ides, youll need to know what a project is. a project is a collection of interrelated source files that are compiled and linked to make up an executable windows-based program or a dll. source files for each project are generally stored in a separate subdirectory. a project depends on many files outside the project subdirectory too, such as include files and library files. experienced programmers are familiar with makefiles. a makefile stores compiler and linker options and expresses all the interrelationships among source files. (a source code file needs specific include files, an executable file requires certain object modules and libraries, and so forth.) a make program reads the makefile and then invokes the compiler, assembler, resource compiler, and linker to produce the final output, which is generally an executable file. the make program uses built-in inference rules that tell it, for example, to invoke the compiler to generate an obj file from a specified cpp file. in a visual c+ 6.0 project, there is no makefile (with an mak extension) unless you tell the system to export one. a text-format project file (with a dsp extension) serves the same purpose. a separate text-format workspace file (with a dsw extension) has an entry for each project in the workspace. its possible to have multiple projects in a workspace, but all the examples in this book have just one project per workspace. to work on an existing project, you tell visual c+ to open the dsw file and then you can edit and build the project. visual c+ creates some intermediate files too. the following table lists the files that visual c+ generates in the workspace.file extensiondescriptionapssupports resourceviewbscbrowser information fileclwsupports classwizarddepdependency filedspproject file*dswworkspace file*makexternal makefilencbsupports classviewoptholds workspace configurationplgbuilds log file* do not delete or edit in a text editor. 3.2 the resource editorsworkspace resourceviewwhen you click on the resourceview tab in the visual c+ workspace window, you can select a resource for editing. the main window hosts a resource editor appropriate for the resource type. the window can also host a wysiwyg editor for menus and a powerful graphical editor for dialog boxes, and it includes tools for editing icons, bitmaps, and strings. the dialog editor allows you to insert activex controls in addition to standard windows controls and the new windows common controls (which have been further extended in visual c+ 6.0). chapter 3 shows pictures of the resourceview page and one of the resource editors (the dialog editor). each project usually has one text-format resource script (rc) file that describes the projects menu, dialog, string, and accelerator resources. the rc file also has #include statements to bring in resources from other subdirectories. these resources include project-specific items, such as bitmap (bmp) and icon (ico) files, and resources common to all visual c+ programs, such as error message strings. editing the rc file outside the resource editors is not recommended. the resource editors can also process exe and dll files, so you can use the clipboard to steal resources, such as bitmaps and icons, from other windows applications. 3.3 the c/c+ compilerthe visual c+ compiler can process both c source code and c+ source code. it determines the language by looking at the source codes filename extension. a c extension indicates c source code, and cpp or cxx indicates c+ source code. the compiler is compliant with all ansi standards, including the latest recommendations of a working group on c+ libraries, and has additional microsoft extensions. templates, exceptions, and runtime type identification (rtti) are fully supported in visual c+ version 6.0. the c+ standard template library (stl) is also included, although it is not integrated into the mfc library. 3.4 the source code editorvisual c+ 6.0 includes a sophisticated source code editor that supports many features such as dynamic syntax coloring, auto-tabbing, keyboard bindings for a variety of popular editors (such as vi and emacs), and pretty printing. in visual c+ 6.0, an exciting new feature named autocomplete has been added. if you have used any of the microsoft office products or microsoft visual basic, you might already be familiar with this technology. using the visual c+ 6.0 autocomplete feature, all you have to do is type the beginning of a programming statement and the editor will provide you with a list of possible completions to choose from. this feature is extremely handy when you are working with c+ objects and have forgotten an exact member function or data member namethey are all there in the list for you. you no longer have to memorize thousands of win32 apis or rely heavily on the online help system, thanks to this new feature. 3.5 the resource compilerthe visual c+ resource compiler reads an ascii resource script (rc) file from the resource editors and writes a binary res file for the linker. 3.6 the linkerthe linker reads the obj and res files produced by the c/c+ compiler and the resource compiler, and it accesses lib files for mfc code, runtime library code, and windows code. it then writes the projects exe file. an incremental link option minimizes the execution time when only minor changes have been made to the source files. the mfc header files contain #pragma statements (special compiler directives) that specify the required library files, so you dont have to tell the linker explicitly which libraries to read. 3.7 the debuggerif your program works the first time, you dont need the debugger. the rest of us might need one from time to time. the visual c+ debugger has been steadily improving, but it doesnt actually fix the bugs yet. the debugger works closely with visual c+ to ensure that breakpoints are saved on disk. toolbar buttons insert and remove breakpoints and control single-step execution. figure 1-3 illustrates the visual c+ debugger in action. note that the variables and watch windows can expand an object pointer to show all data members of the derived class and base classes. if you position the cursor on a simple variable, the debugger shows you its value in a little window. to debug a program, you must build the program with the compiler and linker options set to generate debugging information. figure 1-3. the visual c+ debugger window. visual c+ 6.0 adds a new twist to debugging with the edit and continue feature. edit and continue lets you debug an application, change the application, and then continue debugging with the new code. this feature dramatically reduces the amount of time you spend debugging because you no longer have to manually leave the debugger, recompile, and then debug again. to use this feature, simply edit any code while in the debugger and then hit the continue button. visual c+ 6.0 automatically compiles the changes and restarts the debugger for you. 3.8 appwizardappwizard is a code generator that creates a working skeleton of a windows application with features, class names, and source code filenames that you specify through dialog boxes. youll use appwizard extensively as you work through the examples in this book. dont confuse appwizard with older code generators that generate all the code for an application. appwizard code is minimalist code; the functionality is inside the application framework base classes. appwizard gets you started quickly with a new application. advanced developers can build custom appwizards. microsoft corporation has exposed its macro-based system for generating projects. if you discover that your team needs to develop multiple projects with a telecommunications interface, you can build a special wizard that automates the process. 3.9 classwizardclasswizard is a program (implemented as a dll) thats accessible from visual c+s view menu. classwizard takes the drudgery out of maintaining visual c+ class code. need a new class, a