Lou, a programmer who lives in Endwell, New York, can be reached on CompuServe at 71055,1240. Steve is president of G&A Consultants, an OS/2 consulting firm in Research Triangle Park, North Carolina. He can be reached at ganda@ibm.net.
Dave Edson is a Windows-programming support engineer at Microsoft, which means he spends his days answering real-world questions from Windows developers who use Visual C++. Dave's Book of Top Ten Lists for Great Windows Programming is a compilation of tips and techniques that he invented or discovered in that daunting job.
As its title suggests, the book is organized into top-ten lists, after the fashion of that other Dave. At a higher level, the book consists of four sections: "General Windows Stuff," "Windows NT & Windows 95 Specialties," "MFC" (the book never mentions OWL or any other framework, which is not too surprising, considering Edson's employer), and "Programming à la C." The last section (Chapters 17 through 22) was written by Robert Schmidt, not Dave Edson, and contains nothing that is Windows specific.
In the 16 chapters he writes, however, Edson presents some valuable material. He covers numerous techniques that I don't remember seeing anywhere else, and for that reason alone I'm glad I bought the book. (Even one such item used in a real program makes this book worth several times its price.) He presents chapters on Windows architecture, resource leaks, common Windows-programming problems and mistakes, MFC tips and techniques, and Win32 and Windows 95 programming.
For example, two of the more inventive techniques are in Chapter 7, "Tricks, Hints, and Techniques for Programming in Windows." The first, "Create Invisible Windows to Eat Input During Gigunda Tasks," addresses the problem of impatient users. As Edson points out, even if you display the hourglass cursor during a long-running task, a user will often go on a mouse-clicking binge, queuing up events that are processed in rapid order once your program completes its processing. Edson's first solution is to create an invisible window that does a SetCapture and funnels all events to DefWindowProc. Freezing the user out of all mouse input is "extremely non-multi-tasking aware," as Edson says, so you and your users might prefer his second approach: Create a transparent window that covers your application and swallows messages, but doesn't use SetCapture. Your user can't create an event backlog, but is still free to work with other programs while yours is busy.
The second technique is "Change a Window from a Popup to a Child Window and Back--Without Hacking." While Edson doesn't actually show you how to do this, he does describe a way to simulate it. I'm sure Edson is right, and there is no way to toggle a window between being a popup and a child by fiddling its style bits. But his solution is clever and nearly as good: Create two windows, one a child and the other a popup, that both use the same window callback function. Your program then hides one window and displays the other, and can switch between them as circumstances require different window characteristics.
The centerpiece of the book is the 280-page Chapter 11, "Windows 95 User Interface Goodies," a strong introduction to the Windows 95 common controls--image lists, tree views, rich-edit controls, toolbars, status bars, property sheets, header controls, list views, hotkeys, and spinners. Instead of presenting short tips as he does elsewhere in the book, Edson provides a primer on each control, complete with API details and sample programs. The property-sheet control, which is likely of greatest interest to readers, has two sample programs: one demonstrating the MFC 3.0 support for this control, and another showing a bare API implementation via COMCTL32.DLL. Oddly, neither program is included on the accompanying diskette, although both are listed in the book.
Robert Schmidt's book-within-a-book is well done and presents considerable forward-thinking advice for all C and C++ coders, not just Windows programmers. Schmidt covers issues such as the difference between K&R C and ANSI C, as well as surprises you might encounter when moving to C++. He finishes with his most thoughtful chapter, "Reasons Not to Migrate from C to C++." Based on much of the production C and C++ code I see, I hope Schmidt's chapters are widely read and taken to heart.
Still, the book has its quirks, beginning with Edson's colorful writing style (which he acknowledges by thanking his editors for "letting me get away with so much goofiness in my articles"). Whether you find this "goofiness" refreshing or annoying is a matter of personal taste. In almost all cases I thought Edson's colorization was fun without being intrusive. However, I felt he went overboard with Chapters 3, 12, and 15: "Party Phrases to Ensure that You Maintain Your Computer Nerd Status," "Names of Pets Owned by Windows Programmers," and "Pre-IBM PC Trivia." These self-indulgent chapters, while short, don't add enough to the book to justify their presence.
I was bothered by the underlying assumption of the book--that the topics covered can or should be addressed in lists of exactly ten items. This assumption leads to oddities, such as item #1 in Chapter 16, "MFC Programming Checklist: Use OLE," which is nothing more than a suggestion to use OLE in your programs, and a pointer to Kraig Brockshmidt's book Inside OLE2 (Microsoft Press, 1994). I doubt that any intermediate/advanced Windows programmer (the stated target audience for this book) still needs this advice in 1995.
The biggest drawback of Edson's book is that it appears to have been rushed through production. I was disappointed at the number of typos (for instance, "wierd" and "anyting" on the same page). Similarly, the accompanying diskette, while a useful resource, has its own problems. Only one of the over 20 programs has a .MAK file, a small but needless hassle. Most annoying of all, three of the programs would not compile without errors until I made minor changes that had nothing to do with the still-fluid Windows 95 API. In one case, I spent over an hour trying to determine why one of the rich-edit examples worked, while the other wouldn't allow me to change text attributes. I finally discovered that the defective program wasn't setting the length field in a structure that it passed to the RTF control.
These problems and quirks aren't reason enough to avoid this book, but they're bothersome in a $40 package. Edson's book feels like a useful Windows program that lacks online help and is saddled with a conspicuously ugly icon. Whether that's enough to keep you from adding this title to your shelf is a personal decision.
--L.G.
Every newbie needs a guru. You know who I mean: those wise and experienced hackers from the dumb-terminal era who have forgotten more about bit-hammering than you or I can ever hope to learn. When I began programming, my guru was archetypal, prone to offering Yoda-like koans at the drop of a paradigm. (Come to think of it, he looked a lot like Yoda.) For instance, one of his favorite Delphic proclamations was: "As you grow as a programmer, you're always hitting walls. And you'll hammer at that wall for the longest time, to no avail. Til one day you will find a weapon that will smash the wall and allow you to break through to a whole new level of expertise. That weapon will always turn out to be a book."
Looking back, his words are still true--and never more so than in the last few months, when my time has been spent pounding on the endless mysteries of the OS/2 C++ Class Library, an exercise designed to make even the most hard-bitten keyboard cowboy whimper with frustration. I finally broke through the wall with the help of a book whose uninviting title is OS/2 C++ Class Library: Power GUI Programming with CSet++. Weighing in at 879 pages, the book is intimidating. Don't let this put you off, however. Deal with this intimidation factor, and sink your teeth into the book. If you're programming in OS/2 C++ and hope to master the Class Library, you can't afford not to read it. Besides, you will be surprised and delighted at how approachable and downright sensible the authors, who are all IBM employees, make it all seem.
Make no mistake: The authors expect you to understand programming to the OS/2 Presentation Manager (PM) and C++ programming at the outset. This is not a book for beginners. The authors make no bones about having a lot of ground to cover and little time to dawdle, waiting for you to play catch-up.
If you are not quite sure if you are an "advanced beginner" or a "novice seasoned professional," the first three chapters will help you get situated. You will be led through the theory behind object-oriented user interfaces, the basics of programming using the User Interface Class Library, and a number of PM concepts that are important within the object-oriented framework. If you're more advanced, you may not need this material, but give it a skim anyway--it's good stuff.
The real guts of the book begin with Chapter 4, which gives an in-depth analysis of the Class Library from an architectural perspective and maps this to the message-based paradigm that drives PM. The authors also reveal the behaviors and attributes that are common to all the window classes. The chapters that follow assume you have digested and understood the concepts advanced in Chapter 4, so tuck in and give it some serious attention. Read it twice if need be, to avoid foundering later on.
If you are programming to PM, you are by definition living and breathing nothing but windows and controls all day long. This is the subject matter of Chapters 5 through 15. If you understand Chapter 4, you will be okay here, although that is not to imply that you will find it easy going. If you are like me, you feel that you've already paid your dues once by learning how to program to the straight PM C API. Prepare to ante up a whole new set of dues as you learn how the Class Library manages frames, menus, static and input controls, buttons, and the relatively new CUA91 controls (sliders, containers, and notebooks). You will even get to cut your teeth on the powerful, underutilized Canvas control. It is to the authors' credit that they are able to tie the concepts and APIs together so beautifully and keep you from being overwhelmed.
Although the OS/2 sun rises and sets on windows, buttons, and frames, the Class Library also delivers a lot of solid function in terms of encapsulating things that are not graphical. Chapters 19 through 26 analyze this capability in detail, easing you as gently as possible into a whole new way of dealing with the back-end coding that actually gets the real work done. For a set of classes that were, as the authors modestly claim, essentially cobbled together on an ad hoc basis, you can't help but be impressed with the thorough job the developers did with these areas. Applications and Threads both have a solid set of classes, and the Class Library drag-and-drop classes are exponentially less painful to deal with than enabling drag-and-drop with straight PM. The chapter on the DDE classes is well written, a blessing given the surprising (and occasionally mind-numbing) wealth of classes that exist to enable dynamic data exchange within and between programs.
I found the chapter on the Help classes odd; I could not help wondering if it were really necessary to create classes to manage Help interactions, which I personally always found to be fairly painless under regular old PM. However, give it a browse and see if you prefer the OO method. Maybe I am getting old, but I had the same reaction when reading the chapters on the Resource classes and the Profile classes. A little voice in my head kept chiming in, "yes, that's an interesting approach, but is it really an improvement over the old-fashioned way of getting things done?". I don't think so, but, again, you may find the indefinable flavor of the OO approach to these aspects of OS/2 programming to be just the ticket.
The book finishes with two elegant chapters on problem determination, packaging, and performance. Gone are the days when we debugged our apps using cleverly placed printf() statements; in the object-oriented universe, the inner workings of a given object are obscure by design, and you will want to devote the time and energy to mastering the Class Library's ITrace class. The authors also address the issue of performance and packaging and offer handy hints to reduce the bloats (let's face it, C++ GUI programming is sexy, but without some hand-crafted attention, the GUIs run hog-slow and the bloody executables are huge).
This is yet another outstanding technical guide authored by a group of IBMers. This trend gives me hope that IBM has finally abandoned the "If You Build It They Will Come" mindset that has hobbled efforts to make OS/2 more approachable to the programming community. Maybe, just maybe, IBM has realized that it has to turn its people loose to do what so many of them seem quite good at--namely, showing us how to get things done in the real world using OS/2.
--S.G.
Dave's Book of Top Ten Lists for Great Windows Programming
Dave Edson
M&T Books, 1995, 751 pp., $39.95
ISBN 1-55851-388-4
C++ Class Library: Power GUI Programming with CSet++
Kevin Leong, William Law, Robert Lowe, Hiroshi Tsuji, and Bruce Olson
Van Nostrand Reinhold, 1994, 879 pp., $39.95
ISBN 0-442-01795-2
Copyright © 1995, Dr. Dobb's Journal