Table of Contents


Introduction

Are you an MFC programmer? Good. There are two types of MFC programmers. What kind are you? The first kind are the good programmers who write programs that conform to the way MFC wants you to do things. The second bunch are wild-eyed anarchists who insist on getting things done their way. Me, I’m in the second group. If you are in the same boat (or would like to be) this book is for you.

This book won’t teach you MFC—not in the traditional sense. You should pick it up with a good understanding of basic MFC programming and a desire to do things differently. This isn’t a Scribble tutorial (although I will review some fundamentals in the first chapter). You will learn how to wring every drop from your MFC programs. You’ll discover how to use, abuse, and abandon the document/view architecture. If you’ve ever wanted custom archives, you’ll find that, too.

Why This Book?

You have to have a license to practice medicine. Or do you? I was reading an editorial the other day that proposed that specific employees at HMOs and insurance companies were, in effect, practicing medicine without a license. Here’s how it works: Your doctor suggests an expensive procedure for you, but your insurance company won’t cover it because it isn’t (in their opinion) necessary. So you don’t have the procedure.

The insurance company would argue that they aren’t practicing medicine. You are free to get the procedure done at your own expense. However, with the price of medicine today, an insurance company’s refusal to pay is tantamount to refusing you the treatment.

Windows programming has some interesting parallels to this situation. OLE is difficult to do, so you use MFC. That makes it easy. Sure, you are free to implement OLE on your own (perhaps a man-year of development). But if you want to do it in three days, you’d better stick with MFC.

Generally, MFC is a good thing. But if you use it for something, you essentially have to buy into everything it provides. You can’t just use the OLE part (or the print preview part, or splitter windows). When you use MFC, you are agreeing to do things the MFC way.

Even inside MFC, you’ll find the same phenomenon. Did you know that you can use dynamic data exchange (DDX) with any window that child controls? However, Class Wizard only helps you work with certain kinds of windows (like dialog boxes). Because using DDX without Class Wizard is poorly documented, this—in effect—limits how you use DDX.

One of the great things about being a programmer is that you get to create. I often think that software, if it’s done right, is one of the purest forms of creation available to man. Think about it. You dream up an idea for new software, mumble over your keyboard for a few hours, and voilà, a new creation comes to life. If you type well enough, it is almost as though the program pours from your mind to the computer. Tools like MFC should help you realize your creations, not constrain them.

Ye Olde Days

The first computers I did any serious programming on were embedded microcontrollers that I designed. Here, creativity was king. Anything I could dream up, I could write (subject to my 4K of ROM). The problem was that you had to dream up every detail, no matter how small. In those days, I spent time writing code to pick apart bytes and send them over a software-driven RS232 port. I had to count interrupts to figure out the time of day. Clearly, too much creativity can be a bad thing.

Today, you don’t have to deal with these minute details. If you want to send something to a serial port, you open it and dump bytes out of it. Better still, if you want to talk to a mouse, a modem, or a printer, there are higher-level ways of accessing them so that you don’t even have to care about the serial port that might connect them to the PC. But what you gain in productivity, you lose in creativity. Whereas at one time you could control every detail, now you must suffer the whims of whatever operating system you use.

This isn’t necessarily a bad thing. Who wants to write their own routines to read and write to the hard disk? Will the routine work with every hard disk on the market? Do you really want to write code for each type of printer and display card? Usually, the answer is no. But these are low-level details. What about the higher-level details, such as user interface style? Windows constrains you somewhat even at this level. But here’s the catch: The higher-level the tool, the more it constrains you.

The ultimate example is languages like Visual Basic. VB is great at doing certain things. If your program does the things that VB is good at doing, you’d be crazy not to use it. Point, click, and ship. But what happens when your program does things that VB isn’t good at? That’s different. You can often tweak VB to do something that it isn’t supposed to, but that takes work. At times, it can take lots of work. Often, you are better off using a more flexible language. Therefore, VB, like all tools, sets constraints on the kinds of solutions you design.

MFC Constraints

What constraints do you suffer as an MFC programmer? Plenty, even if you don’t realize it. MFC constrains you in several ways:

  MFC has a distinct architecture that many of its pieces rely on.
  When MFC offers a component or a class, it is often easier to use it as-is than it is to develop a new one (or enhance the old one).
  MFC’s tools (App Wizard and Class Wizard) only work with certain kinds of programs; it is difficult to create other kinds of programs because they won’t help you.

This book is all about breaking free of those constraints. Sometimes that means taking on a lot of work. Sometimes it’ll be easy, if you know how. In every case, you’ll achieve your goals by working with MFC. You don’t have time for hacks that might not work with later versions of MFC.

Of course, being different for its own sake isn’t a good idea either. For example, putting your File menu in the middle of the menu bar violates the famous Shock Minimization Principle (SMP). This is the software engineering axiom that states: Software shall operate in such as way as to minimize shock to the most users.

On the other hand, there are plenty of cases where you’d like something to work a bit differently. You’d like to exercise your creativity and develop something that no one has ever seen before, right? That’s the goal of this book: To help you to realize your programming vision.

Using This Book

To get the most from this book, you should have a copy of Microsoft’s Visual C++ 5.0 or later. You can probably use most of the techniques with other versions of C++ from Microsoft or other vendors, but the code in the listings and the CD-ROM use VC++ 5.0.

Each chapter covers a particular topic. The first part of the chapter contains detailed information about the chapter’s topic. The second part shows practical problems and cookbook-style solutions to them. This might be references to the MFC technical notes, Web pages, or magazine articles.

Each chapter can stand apart from the rest. If you have a specific problem, you might want to thumb through the practical guide sections at the end of each chapter. Of course, you should only use the solutions as a guide. After all, you want to exercise your own creativity.

Perhaps you have a vision for your software. Maybe your customers, your boss, or your competition are pushing you to produce your software a certain way. In either case, pick a chapter and learn how to do things your own way.


Table of Contents