MFC Internals: Inside the Microsoft Foundation Class Architecture
Author: George Shepherd
The first half of the book covers core Windows graphical user interface classses and their supporting classes; the second half covers subjects like OLE that are extensions to the basic Windows support. You'll become an expert at understanding MFC implementation details by:
- exploring under the hood of MFC's document/view architecture to learn about view synchronization, printing and even print preview
- diving deep into undocumented aspects of MFC serialization and undocumented classes like CPreview, CPreviewDC, CMirrorFile, CDockBar, etc.
- finally learning how MFC and OLE work together under the hood, and how OLE controls are implemented
- building the skills that help you investigate and understand MFC source code on your own
MFC Internals focuses on MFC 4.0 for Windows 95 and Windows NT. Most key "internal" concepts also apply to previous versions, but where they don't, the authors warn you with a version note. The book's disk contains example code and the MFC FAQ file, and be sure to check outAppendix A, a handy MFC source code field guide.
MFC Internals is an essential guide to tapping MFC's rich and robust application framework and applying advanced MFC knowledge in world-class Windows applications.
0201407213B04062001
Emily Berk
Telling It Like It Is, Not How It Should Be
What we've lost now that "user-friendly" days are here and structured programming is passé is the concept of right and wrong in programming. Everyone strives to encapsulate reality, but, perhaps because everyone's reality differs, every developer's concept of the right way to implement an application differs as well. What was science has become art. But don't let Microsoft or any other tool vendor fool you -- software engineering still isn't easy to do. Developers may have fewer lines of code to write, but they have to think more about each line of code.
The tool a developer uses to create applications influences the reality that gets encapsulated. These days, Windows developers' reality is often constrained by Microsoft's Visual C++. That means Windows developers must know the SDK, C, and C++ and the peculiar assortment of building blocks and C++ extensions called the Microsoft Foundation Classes. (Did someone tell you that we didn't need to know the SDK anymore now that we have Visual C++? Sorry to disappoint you I have, actually, written programs using Borland C++ where I never needed my SDK docs, but that was in an alternate universe, one where I didn't need to call Create() after every new.)
MFC is a work in progress. It's nigh on impossible for the ordinary person to determine all its features and pitfalls using the documentation that Microsoft provides, let alone to follow its evolution; it changes quarterly. In fact, because MFC's documentation is usually shipped on-line only, it's hard to find out about something unless you know its name and how to spell it. Knowing a good deal about the history of VC++ itself helps as well. (My favorites are the functions that begin with "Afx"... Try finding out about these if you forget the "Afx"!)
That's why many MFC developers learn MFC by trial and error. You write something, it compiles fine, you run it and it blows up, and, once you fix the problem, you've learned something. Or, you read about an interesting class, spend time designing an object that seems appropriate, but then it turns out, you really can't use that class to construct that object, at least not in the way you conceived of it.
In addition, much information of vital importance to developers is simply not documented in any of the materials that accompany this compiler. And, few books about Visual C++ convey much of this vital information either. In fact, most books about MFC do little more than restate the documentation provided by Microsoft. What we need is a book that tells it the way it is, not the way it is supposed to be.
That's why, if you program in MFC, you need MFC Internals. Shepherd and Wingo don't dazzle us with science. MFC Internals has few pretty pictures and it comes with a plain old floppy disk, not a CD. The text of the book is not on the disk, nor is there code for every chapter. But there are a number of un-assuming but interesting little programs, alluded to in the book, that relate to particular topics of interest. The authors don't tell us everything we might want to know about them, but they give us enough to get started.
MFC Internals has little flow, either, which is actually an advantage in a book of this type. It's advisable to read whole chapters in order, but you don't necessarily have to read the first five chapters to understand the sixth. The authors provide helpful suggestions about which chapters to read together early on in the book.
MFC Internals is not a book for those just learning Visual C++. It doesn't tell newbies how to use an App Wizard, or how to use the IDE. You need to use VC++ for a while, notice its good features, get frustrated by its idiosyncrasies, before you can appreciate a work like this one.
MFC Internals gets specific where other reference sources about Visual C++ stop. Take, for example, MFC's much-hyped Document-View architecture. Even in the bad old days of linear programming, we knew that separating data from the display of data was a good idea. Doc-View plays a prominent part in every MFC program, but, in my experience, is so poorly explained and implemented in MFC that the average MFC programmer doesn't take advantage of it.
MFC programmers talk the Document-View talk, but never venture past the document templates the App Wizards generate. The learning curve spirals abruptly upwards every time you try to do anything interesting with MFC's CDocument or CView classes, not to mention the CDocTemplate classes, which I haven't found documented usefully anywhere until MFC Internals.
Discussion of the Document-View architecture and, especially, the distinctions between the Multiple Document Interface (MDI) and Single Document Interface (SDI) proves treacherous for most authors. Document-View should mean that I can display a single document (or, data source) in a variety of formats. But, actually, MFC's SDI precludes displaying multiple views of a single document, except in its brain-dead splitter windows. Most authors are, perhaps understandably, reluctant to come out and say that Microsoft has made it almost impossible to create a useful SDI application using the tools MFC makes public.
Which is probably why most authors cave. They define terms exactly as they are defined in the MFC docs. They throw in one brain-dead SDI example with a splitter window. Then, they spend pages and pages explaining how MDI is the way Microsoft implements important applications like Word and Excel. So, all these books imply, isn't MDI the way we all really want to go, because we want all our applications to look like just Microsoft's Word and Excel don't we?
Contrast this with the exposition of Document-View in MFC Internals. Politically skirting the issue of why SDI allows only a splitter window, Shepherd and Wingo thoroughly define all the terms and tell us what Microsoft's rules for them are. Fairly often, they throw in something like: "You don't need to use a CView here, but you lose some of the functionality of the CView." I believe that this is where they are recommending that we go around Doc-View, and then they tell us how. Later, in discussing document templates, they say "You can use frames/views/documents without relying on CDocTemplate or any of its derivatives. CDocTemplate really doesn't do anything special other than encapsulate a few common uses of the document/view framework." In other words, CDocTemplates have straight-jacketed us for years, but there is a way around them too.
In the chapters having to do with Doc-View, as in other chapters, MFC Internals shows us the ways around the MFC ties that bind most uncomfortably. In addition, it describes many undocumented classes. Although the authors are careful to say these are subject to change in the future, they also point out which ones are used extensively within MFC itself, which makes it unlikely they will change.
Shepherd and Wingo use quite a few adjectives, admiring ones, natch, in the first chapter or two, but they soon run out of them, which is good. They are quite careful about how they state things that might, in other hands, seem to be accusing Microsoft of not having a clear plan for MFC. Often a historical context is used to show how something evolved to be the perverse mess it is today. In other cases, they'll reproduce a conversation with a Microsoft insider who isn't exactly sure why suddenly something changed. And yet, the authors don't waste time bashing Microsoft or Visual C++. Usually, if they use an adjective like "wacky" to describe something, it's hyperbole. They then proceed to baldly state the pros and cons of Microsoft's decisions.
The choice of topics is good as well. Particularly interesting to me was "Chapter 5: All Roads Lead to CObject", which really does prove that we should be deriving almost everything in our realities from CObject if we want to take advantage of what MFC gives us. The chapters on COM and OLE were obviously written before ActiveX and its associated buzzwords invaded our reality. The concepts may be the same, but the jargon is, unfortunately, not in the index. By the time you've digested the rest of the book, an update to the book will, hopefully, remedy this shortcoming.
Not convinced that this book is for you? Go to your local bookstore and read page 100 of MFC Internals. Observe how Wingo and Shepherd walk that fine line between admiration, skepticism and, is that -- wonder -- when they note how much is not documented. Their wry observations make otherwise dry topics memorable; I learned something new about pretty much every topic covered. But don't read this book until you've developed your first real application in MFC. You need to learn how much you need to learn before you can appreciate MFC Internals.
If only MFC Internals explained why Microsoft forces us to do a Create() after every new, I'd stand on street corners asking developers if they'd been saved and giving away copies of this book....--Dr. Dobb's Electronic Review of Computer Books
Look this: Processed Meats or Business Ethics
Get Rich Click: 350+ Ways to Make a Fortune Online
Author: Marc Ostrofsky
Marc Ostrofsky knows how to “Get Rich Click.” In his first major deal, at age 29, he created and sold technology magazines and trade shows for $7 million. He made headlines selling the domain name Business.com for $7.5 million, landing him in the Guinness Book of World Records. At age 45, he personally owns over 350 web sites such as SummerCamps.com, CuffLinks.com and Blinds.com, which alone does over $50 million annually selling window coverings online-with absolute NO stock or inventory. His recent get rich click venture, Internet REIT, includes investors such as Starbucks founder Howard Schultz and former presidential candidate Ross Perot. The firm owns over 350,000 domain names and sells the traffic from those sites to Google on a monthly revenue share basis. He is a serial entrepreneur and professional speaker on the topics of making a fortune on the internet and entrepreneurship.
Each of Ostrofsky's wildly successful ventures started from a simple, low-cost idea based on making money on the internet. What sets them apart is his revolutionary way of viewing the internet. Now, this “technology wildcatter” and entrepreneur offers the definitive guide for anyone who wants to follow in his footsteps.
Get Rich Click outlines a clear-cut path to using the internet to make money-lots of it. Hundreds of examples and case studies for new income opportunities, plus profiles of actual entrepreneurs, offer unlimited opportunity for getting rich online.
No comments:
Post a Comment