COM From All Angles

It’s a little-known fact that Visual Basic is the leader of an insidious conspiracy to take over the world for COM. Here are some of the ways Visual Basic preaches and practices the COM doctrine.

• Controls. Visual Basic changed the world by popularizing the concept of a visual interface object encapsulated in an independent executable file known as a control. We’ve come a long way since then. Controls came before COM, but now ActiveX controls are a part of COM. Although there are differences under the surface, they’re still
  as easy to use and as revolutionary as they were in Visual Basic version 1.0.
  
  
• ActiveX Controls. Now you can write your own ActiveX controls in Visual Basic. This is a dangerous new capability. It’s very easy to write bad controls. It’s moderately difficult to write good ones. But a lot of Visual Basic programmers will meet the challenge. This is going to change the world again.
  
  
• ActiveX DLLs. The Visual Basic run-time library is an ActiveX DLL. My VBCore component is an ActiveX DLL. You can enhance the language by adding your own ActiveX DLLs. They can have global functions and public classes, just like the Visual Basic library.
  
  
• Type Libraries. Visual Basic supports type libraries (which you install with the References dialog box and view in the Object Browser). Most well-behaved COM components, including the Visual Basic libraries and controls and any components you create with Visual Basic, have type libraries. Another kind of type library makes a non-COM DLL (such as the Windows system DLLs) look like a COM object. The Windows API type library supplied with this book is such a library. See Chapter 2 for details about how to load it in the References dialog box and how to use the functions in it.
  
  
• Interfaces. You create them and use them behind the scenes all the time. Now you can write your own and implement them. You can also implement standard interfaces supplied by COM or Windows, although this isn’t as easy as it ought to be. Nevertheless, you’ll do it in this chapter.
  
  
• Object Linking and Embedding (OLE). OLE is now a tiny subset of COM. If you took seriously the title of this chapter in the first edition (“The OLE Gospel”), repeat with me: “Won’t get fooled again.” Anyway, Visual Basic supports linking and embedding through the OLE control. Using this control is too easy for a hardcore book, so this is the last time you’ll see the insignificant term OLE.
  
  
• COM Automation. Visual Basic allows you to program applications that expose themselves through COM Automation. I see a lot of requests for assistance with this, but most are concerned with the application side of the problem. I’m not going to talk about programming the object models of applications such as Microsoft Word for Windows, Microsoft Excel, and Visio because I don’t know which ones you have. Besides, other books cover this topic. Microsoft Press publishes two good ones: Developing Applications with Microsoft Office
  for Windows 95, by Christine Solomon (1996); and Microsoft Guide to Object Programming with Visual Basic 4 and Microsoft Office for Windows 95, by Joel P. Dehlin and Matthew J. Curland (1996).
  
  
• Add-Ins. The Visual Basic environment is itself a COM Automation server. You can customize it by creating your own components in
  a specific format known as an add-in. Add-ins must program the en­viron­ment’s VBIDE object and must provide objects that the VBIDE
  object knows how to talk to. I described and enhanced the add-in model in the first edition of this book, but the whole thing changed for Visual Basic version 5. The version 4 model was notoriously wimpy,
  so the new model has to be better. But I didn’t have time to figure out how much better. Add-ins aren’t covered in this edition.
  
  
• ActiveX Documents? Yes, but not in this book.