Chapter 18

MFC and the Component Object Model

In the beginning, when MFC was still in its infancy, C++ programmers who began migrating from the Microsoft Windows API in favor of MFC did so because they wanted a class library to aid them in developing Windows applications. The conventional wisdom at the time said that MFC made Windows programming easier, but the truth of the matter was that Windows programming was still Windows programming. MFC simplified certain aspects of the development process, and for those few programmers prescient enough to adopt it early on, it eased the pain of porting 16-bit Windows applications to 32 bits. But even MFC could hardly claim to put a dent in the legendary Windows learning curve. That was true then, and it's still true today.

Today there is another, more compelling reason to use MFC. If the applications you develop have anything whatsoever to do with COM, OLE, or ActiveX, MFC can dramatically simplify the development process. By that, I mean MFC can cut the time required to develop an application (or a software component) by an order of magnitude. In this day and time, there is simply no good reason to develop certain types of software from scratch given that such good class libraries are available. COM, OLE, and ActiveX have been criticized for being overly complex and hopelessly arcane, but for better or worse, they're here to stay, and there's a very real chance that in the future you'll have to be a COM programmer if you want to program Windows.

So what are COM, OLE, and ActiveX, and what does MFC do to make them so much easier to program? I'm glad you asked, because the rest of this book is about MFC's support for all things COM. In this chapter, I'll begin by defining COM, OLE, and ActiveX, and then I'll introduce some of the unique and interesting ways in which MFC wraps its arms around them. In subsequent chapters, we'll tackle specific COM-based technologies such as Automation and ActiveX controls and you'll see how to use MFC to make them come to life.