In his Republic, Plato uses the image of flickering shadows to illustrate a point. He draws an image of men sitting in a cave, facing a wall and bound in such a way that they cannot look anywhere but forward, ahead of them. With the opening of the cave behind them, they are forced, from birth, to view their world solely in terms of the shadows cast by themselves (and, in Plato's vision, the shadows cast by puppets being manipulated by a puppeteer in the space behind them).
Plato then tells how their views of the world will be misguided, inaccurate, and dangerously misleading. He points out that to bring them into enlightenment, to turn them around, and show them the light, will be painful for many of them (their eyes not being accustomed to looking into the brightness), and many will flee back to the comfortable darkness, safe in their former assumptions.
Taking this analogy one step further, we can liken the men on the cave floor to all of the world's C++/Windows developers who, for years, labored under the idea that Windows applications had to be written in the same style as the code that Microsoft shipped as part of the software development kit (SDK)--it had to be in C, it had to have a huge WndProc , and so forth. Microsoft Foundation Class (MFC) and Object Windows Library (OWL) helped to disabuse us of that view, but, even then, many labored under the idea that MFC was the only way Windows apps could be developed using C++. Those of us who could stand the bright sun in our eyes long enough to let them adjust realized that our applications could be written in a better way, using OWL and its more object-oriented programming (OOP) approach. (Most MFC programmers I've spoken with who've used both frameworks agree that OWL is the more intelligent OOP design.) We've gone through the pain of the adjustment to a more highly abstracted, more cleanly designed framework, and our applications (and our source code) reflect that.
In many ways, those men sitting on the cave floor are themselves OWL programmers, though not through any fault of their own. The body of written work on OWL is pitifully small when compared to the volumes written for its competitor, MFC. And unless you know where to look, the world of OWL programming can be a pretty dark, shadowy place.
Welcome, I hope, to the light. I believe once the pain has passed, you'll suddenly find your OWL applications (and designs) gaining new strength and new power. Like Virgil to Dante, let's take this little trip together, and see where we end up, shall we?
The Borland documentation leaves much to be desired, not because it doesn't cover the subjects it covers well, but because there's a lot that the documentation doesn't cover. The Borland documentation has not kept up with the growth of OWL. To compound matters, all of the after-market books on Borland's C++ product discuss the compiler, some C++, and perhaps a bit of OWL. This book is designed to help you get a firm grip on all aspects of OWL, from the underlying libraries, to the high-level abstractions used to make tasks like docking toolbars easier.
OWL 5.0 has almost doubled the size of OWL 2.5 (not counting the ObjectComponents Framework (OCF), or the Borland International Data structures (BIDS), components), and has easily more than doubled the capabilities you now have before you. It brings to you all of the new controls spawned by Windows95's CommonControls dynamic link libraries (DLL), like RichEdit and ImageList controls, as well as introducing new user-interface components of its own, like the TRollDialog and the TPickList . Common document-centered capabilities have been thrown in too, like the TRecentFiles mixin class, as well as dockable toolbars.
More importantly, OWL 5.0 has not forgotten its roots, nor the fact that not everyone is moving to Windows95 or has the hardware to effectively run NT. Much of the OWL capabilities, those that aren't restricted to Win32 (like preemptive multithreading or Unicode), are either graciously handled or implemented by hand for 16-bit Windows.
OWL 5.0 has capabilities that reach far beyond the imagination. OWL 5.0 has all of the common user-interface idioms your customers and clients and bosses and coworkers are demanding, and has provided them in the same clean, object-oriented style introduced with OWL 2.0. Almost all of your OWL 2.0 code can port over with no recoding necessary (although you may get spurious messages in your Interactive Development Environment (IDE) message window when building), and you can still maintain a single code base for 16-bit Windows, WindowsNT and Windows95.
One of the issues we'll be running into again and again is that despite C++ being viewed sometimes as a better C, C++ and Windows programming do not get along very well. Certain features which provide power in C++ can in turn make things very hassling for Windows, and vice versa. As these issues come up, we'll examine them and see if there are effective and easy workarounds. Windows callbacks versus C++ member functions, C++ name-mangling, runtime dynamic linking, and C++ member functions make the C++ Windows programmer's life a living Heck.
All of this combines to produce a single, inescapable conclusion: OWL programming is not as straightforward as we would like. Combine this with the complex interactions that C++ can provide, and understanding OWL and everything that can happen in your OWL applications can be a daunting task. This book, and its companion volume, Advanced OWL 5.0, should help reduce some of that stress.
What you should know to use this book effectively
I'm assuming a few things before we begin:
OWL 5.0, taking away all the new stuff, is (aside from some bug fixes) the same as OWL 2.x. If you have a good background in OWL 2.x, you should be OK here. If you still think OWL is a type of bird that flies around at night and hoots about cleaning up after yourself while camping, put this book back on the shelf.
If you're not comfortable with OWL, you may want to take a look at one of the more beginning-level OWL texts, such as Teach Yourself OWL 5.0 in 21 Days (Arnush, SAMS Publishing).
You shouldn't have to reach for your favorite C++ book if I start talking about multiple inheritance and virtual base classes. Some of the template usage in OWL may be a bit above the average C++ programmer, especially in some of the new stuff added to TModule and company, but anywhere OWL has taken advantage of the new C++, I'll point it out and make sure to explain what's going on and why. For those of you who don't read the American National Standards Institute (ANSI) draft standard document each week, there's a brief review of the new changes to C++ in the last year or two.
If you're not comfortable with C++, I'd recommend you take a look at a couple of C++ books before diving into this one. Some of my favorites are listed in the bibliography. These books are not C++ tutorials; those of you who count yourself a C++ beginner, consider looking at any of the myriad beginner level books available.
You should be at least passingly familiar with the Windows Application Program Interface (API) (16- or 32-bit). It isn't required, but let me stress that, in my experience, the best OWL programmers are those who are equally familiar with OWL and the API. There are some times, especially during some intricate debugging, when knowledge of what the API is doing can be instructive in finding your bug.
If you're not familiar with the Win16 or Win32 API, I recommend a basic Windows programming book, like Charles Petzold's Programming Windows 3.1, or Jeffrey Richter's Advanced Windows and Windows 95: A Developer's Guide. These books talk API, but the concepts can easily be brought into OWL.