Bruce McKinney
Microsoft Press
April 18, 1996
I can't think of any two languages less alike than Microsoft® Visual Basic® and C++. And yet, when paired, these two parts of the programming problem form a seamless whole. You can have your cake and eat it too!
I know I'm going to catch hell for saying it, but I can't think of a worse language for writing complete applications than C++. Yes, I know. A lot of people write perfectly good applications in this language. With the wizards in Microsoft Visual C++® and other modern compilers, designing dialogs and hooking them up to code isn't nearly as painful as it used to be. Better tools and faster computers make compiling almost tolerable.
But when it comes to drawing forms, I don't want it to be less painful, I want it to be painless. I don't want a fast compiler, I want an interpreter. When creating applications, I don't want to think about pointers and references, I want to think about forms and controls.
That doesn't mean I dislike C++. A complex algorithm coded in tight C++ is a thing of beauty. I've wasted far too much time trying to fake pointers and use callbacks from Visual Basic. Sure, you can do almost anything you want in Visual Basic if you want to prove a point. I did prove a few points in my last book, Hardcore Visual Basic (Microsoft Press, 1995). But this time the point I intend to prove is that you should pound nails with a hammer and fasten screws with a screwdriver. The hammer we're going to use in this article is C++ and the nails will be native code dynamic-link libraries (DLLs) for Visual Basic.
This series of articles was originally intended as a complete book. The idea was to start by creating a type library, move on to creating C++ DLLs, and eventually teach readers how to create OLE objects, including ActiveX™ controls. It turns out I bit off a little more than I could chew in the time allotted. The technology for creating OLE objects changed so dramatically during the early months of the project that I had to throw a lot of my work away. Finally, my time ran out and I had to move on to another project.
The first part of the book—the chapters on type libraries and DLLs—remains valid and useful for Visual Basic programmers trying to extend their programs with C++. Therefore, I adapted them from book form to this series of articles. You can think of the series as a kind of appendix to Hardcore Visual Basic. That book described advanced programming techniques in Visual Basic. This series describes techniques for Visual Basic in C++.
But the usefulness of the articles goes beyond the specific DLL techniques described. You can also apply the information about type libraries and OLE types to any of the technologies for creating OLE objects and ActiveX controls. In the past, most people wrote controls using Visual C++ and the Microsoft Foundation Classes (MFC), but recently several other environments and frameworks for creating ActiveX controls have become available from Microsoft or from other vendors. You'll see even more alternatives soon. These articles don't discuss OLE objects directly, but most of the information can be applied indirectly to any method of creating ActiveX controls or other OLE automation objects.
My last book, Hardcore Visual Basic, contained a solemn oath that I would never again write a book that had the S word in the index. If you don't know what the 16-bit S word is, consider yourself lucky. If you do, just try to find it in any of these articles. For that matter, try finding anything specific about 16-bit programming (except in a historical context). I can't tell you how happy I am to live in a world where memory stretches on and on and 64 is just another number.
The point is, this series of articles is 32-bit only. I know this may be a problem for readers who are less bullish on 32-bit Windows® than Microsoft. I'm not going to go into all the reasons why I chose to target 32-bit Windows in the book on which these articles are based. Some of those reasons don't even apply to this scaled-down version of the material. But there is a very specific reason why I have to be 32-bit only: I developed all the code using Microsoft Visual C++ version 4.0, and that's a 32-bit compiler. Microsoft has a 16-bit C++ compiler, but it's pretty crude and old-fashioned. Specifically, it doesn't support templates or exception handling—two techniques that I use extensively.
I'm not tied to Microsoft compilers by any factor except time. I didn't have time to test the code with other compilers, and I don't want to pretend otherwise. Most of the code in this book would probably work fine under other compilers, including 16-bit C++ compilers if they support templates and exceptions. If you have a compiler from a company more interested in 16-bit programming than Microsoft, the conversion might be relatively easy. I don't know and I'm not going to find out unless you tell me after these articles are published. I will give some hints about technology that might work differently on other compilers or for other operating environments.
I'm sorry to gloat when I know some of you have jobs that require you to continue providing support for 16-bit clients. But after many years of supporting multiple code bases and trying to hack 32-bit code into 16-bit operating systems, I'm not looking back. These articles are 32-bit only, and if you still live in a world with fewer bits, you're on your own.
You should know two things to take advantage of these articles: Visual Basic and a small subset of C++. Let's start with the Visual Basic requirement.
If you're ready to start writing Visual Basic tools in another language, you're probably already a Basic expert. I'm not necessarily ruling out C or C++ experts who don't know Basic. In theory, you could have a team consisting of Basic experts to do the Basic work and C++ experts to do the C++ work, but in practice I've seen too many C++ programmers who thought they were good enough to write tools without understanding the target environment. A lot of what I'm going to talk about would also apply to other OLE environments, such as Delphi®, or VBA-enabled applications, such as Microsoft Excel or Microsoft Access, but you may have a hard time following some parts if you're not specifically familiar with Visual Basic 4.0. If you're still using Visual Basic 3.0, forget it. The techniques for writing DLLs are completely different, and besides, there is no 32-bit Visual Basic 3.0.
I foresee some C programmers coming to these articles with little or no C++ experience. In previous versions of Visual Basic, programmers who were dissatisfied with performance wrote DLLs in C (or assembly language). C++ didn't bring much to the party. In fact, you didn't really need to understand a great deal of C to get started. You could get a big performance boost for bottleneck code just by translating it trivially from Basic to C. That attitude isn't really going to fly with OLE Basic—uh, make that Visual Basic. You're going to have to learn some C++, but not the whole humongous language.
These articles will be using only one of the three pillars of object-oriented programming. We'll be talking about encapsulation, but not about polymorphism or inheritance. My theory is that polymorphism and object reuse should occur on the client side of the equation. I use C++ for low-level coding that Basic can't do efficiently. As a result, some of what we do here will be simply use C++ as a better version of C. We'll also be encapsulating some application programming interface (API) calls in an attempt to make OLE types look and work like intrinsic types.
Faking intrinsic types means using operator overloading, which is a difficult and confusing technique in C++. That's probably the most difficult topic I'll cover, and I won't do much hand-holding. You'll have to learn C++ to understand my examples elsewhere. We'll also be using two relatively new (new to Visual C++ customers, anyway) technologies—templates and exception handling. I'll explain what I'm doing at a somewhat high level, but you may still need other references on these subjects.
There's nothing to prevent you from taking these techniques further. You can probably figure out ways to inherit from my classes or to use MFC classes in DLLs for Visual Basic, but you'll have to do so on your own. I'm trying to give you a foundation for creating Basic tools. What you put on that foundation—castle or bunker—is up to you.