Overview

PrefaceIn the Microsoft and Windows world, objects and components form the foundation on which everything else rests. The mortar for this foundation is Microsoft's Component Object Model (COM) specification and implementation. The COM specification describes how objects can be assembled into components and how components can work together to form applications. The implementation of COM in the Windows operating system provides the support to take advantage of this powerful technology. To participate in the world of COM, you need to create components that will work with any other COM-compliant development tool and application.I wrote this book to provide the working Visual Basic programmer with something that I wanted: A one-volume reference to writing COM-based objects and components using Visual Basic. My goal was to provide, in one place, in plain language, everything that the Visual Basic programmer would need to know to create components.COM and Visual BasicCOM is constantly evolving. Currently COM is being expanded into the COM+ specification in Windows 2000. In both the COM and COM+ models, developers create objects and then combine them to form components. Once built, your components can be integrated with applications built with other development tools ranging from C++ to Delphi to Object COBOL. COM-based applications that can use your components include both Microsoft Word and Internet Information Server. Building on COM, Microsoft has also defined a series of environments—including Microsoft Transaction Server and ActiveX Data Objects—that require objects with specific characteristics. It's a very big world out there.Fortunately, Microsoft has provided a terrific tool for creating objects: Visual Basic. Much of the drudgery involved in creating COM objects and components is taken care of automatically by Visual Basic so that you can concentrate on solving problems. There's still a lot that you have to know, as this book demonstrates, but Visual Basic lets you concentrate on the important issues.I've taken a very practical approach in this book. Throughout the book, I'm going to tell you two things:If you want to do this using Visual Basic, here's the code that you should write.If you write this code, here's what Visual Basic will do.Or, more simply: If you want this, code this; if you code this, you'll get this. Where Visual Basic gives you different implementation choices, I've described the costs and benefits from a design and maintenance point of view for each choice. I've also provided benchmarking information on the impact on your code's performance. I can't tell you what the right answer is for each one of these choices, because too much depends on what you are trying to accomplish with your program. However, if you're wondering what threading model to use or whether to declare your parameters as ByVal or ByRef, this book will give you the background to make an informed decision.I've given design considerations precedence over performance. I don't want to suggest that performance isn't important-the application with the sub-two-second response time and a few bugs will be implemented before the application with plus-six-second response time and no bugs. But for your application to succeed, you must first get the design right and then make the adaptations necessary to get the performance you need. I firmly believe that it's often better to abandon a project than compromise the design in order to meet the performance goals. For most applications, the life cycle cost of a bad design will swallow whatever benefits the application was supposed to deliver.Good design and good performance are not incompatible. If the design is right, then you will probably find that modifying it where necessary to improve the performance is relatively straightforward. Throughout this book I will be pointing out where you have opportunities to ensure that your component will run quickly, along with the costs and benefits of building your component that way.The Knowledge GapBack in the early '80's, I started out programming on mainframe computers and creating linear programs-programs that started executing on the first line of code and kept going until they got to the end of the code. I inserted Do loops, If...Then statements, and subroutines or functions to break up the monotony, but mostly my programs began at the beginning and ran until the end.Programming doesn't work that way anymore. My first exposure to this new world was when I started creating programs using Visual Basic 3.0. My first exposure to "programmer's culture shock" was when Visual Basic introduced me to event-driven programming. In event-driven programming I had to give up control over the execution of my program; the events that were triggered by the user determined the order in which my code executed.When I started developing programs in Visual Basic, I also began to work with the objects that made up the Visual Basic environment. I had experimented with object-oriented programming earlier in my career by learning Smalltalk, the language that pioneered object-oriented development. I discovered that, while I had learned the syntax of the language and could write Smalltalk code, I still couldn't create Smalltalk applications. I just didn't know where to begin. Visual Basic turned out to be the tool that moved me from the world of linear programming to the world of working with objects.For the last three years, in addition to developing Visual Basic applications, I've been teaching Visual Basic to developers for Learning Tree International. Many developers in my classes suffered the same problem that I had in getting started with object oriented development. These programmers found themselves in the position of knowing all the necessary syntax, but unsure about how to put it all together. Experienced developers in my classes found that they knew only part of what Visual Basic could do for them.It was to address this gap between knowledge and performance that I wrote this handbook. In addition to teaching and developing, I wanted to provide developers not only with the knowledge on how to use Visual Basic's ability to create objects, but also the "when and why" of using objects.The HandbookI edit the Smart Access newsletter (the leading source for technical information on Microsoft Access). While working for Learning Tree, I also wrote a course on developing Web-based applications. If you read the various magazines about programming with Visual Basic, then you've probably read an article that I've written. As a result, I've had a lot of experience in explaining technical concepts to programmers. More important, I've had a lot of feedback from students, teachers, authors, peers, and others on what works and doesn't work. I've learned that the key to presenting information successfully is to provide a solid structure to organize the material.This handbook's structure is simple. The first three parts of the handbook discuss designing objects, creating objects and components, and integrating components into specific environments. The fourth part is a "heads-up" look at what changes you can expect in Windows 2000.Part 1 of this book covers the issues involved in designing objects. In this part, I discuss what you should consider when designing the interface for your objects. Among other topics, I'll look at deciding when you should use a method or a property, and how to derive your object design from your data design. I also show you how to use Visual Modeler, the object design tool that comes with Visual Basic.Part 2 provides you with a complete guide to creating objects and components, including the code you need to write to implement methods, properties, and events. You'll see how to develop objects that act as collections and how to create objects that create other objects. In this part I also show you how to combine your objects to create components and cover both the why and how of implementing interfaces. Thanks to Visual Basic, your components can be as complicated as Microsoft's Data Access Objects or as simple and powerful as ActiveX Data Objects.The examples in Part 2 are deliberately simple: Just enough code to demonstrate the technique. However, objects are really interesting only when they are put together and interact with each other. To demonstrate this, most of the chapters in Part 2 end with a case study that shows the various techniques in action. Even in these final sections, I've kept the standard "business" code to a minimum so that you can concentrate on the code that makes the objects work. The error handling that a real business application would require is missing, for instance.With a foundation on how to build objects and components in place, Part 3 looks at how to create objects that will work in the specialized environments that Microsoft has defined. You'll see how to create an object that can pass data into to ActiveX Data Objects and what you must do to create a component that will work with Microsoft Transaction Server. In Part 4, I look at what Windows 2000 developers can expect to find under COM+ and Component Services.BenchmarksThroughout Part 2 of this book I've given examples of the impact on execution time of the programming decisions that you will make. If you are trying to decide whether to use a ParamArray or a set of optional parameters, these benchmarks should provide you with the information to make a performance-based decision. However, performance isn't everything, as you know if you've ever tried to maintain someone else's "highly optimized" code. And, in many cases, a foolish emphasis on writing the fastest code leads to introducing bugs. To paraphrase the immortal words of the authors of The Fundamentals of Programming Style, to some programmers, efficiency often seems to mean getting to the wrong answer as fast as possible.Overreliance on benchmarks can be a mistake. As you look at the benchmark results remember that I repeated most operations 1000 times. So, when I say that an operation took 2 milliseconds on my computer, that really means that one execution took 2/1000 milliseconds. You should recognize that even a difference of an order of magnitude may translate into less than a millisecond. Do you really need to worry about a millisecond? And, if you do, shouldn't you be writing this code in C and not Visual Basic? If you are concerned about the assumptions that I've made, you can find the code in Appendix B, the Benchmarking Code appendix. You can also download the code (and the COM Add-in that generated it) from my Website at phvis.Keep in TouchI've had a lot of fun writing this book and exploring Microsoft's world of objects. I wrote the book because I wanted to provide a single reference to all the information that you might need when building components with Visual Basic. I hope you get as much satisfaction out of using this book as I did writing it. If you have any questions, issues, concerns, or recommendations don't hesitate to drop me a line at peter.vogel@phvis. You're also welcome anytime at the PH&V Information Services website at phvis. In addition to finding the Visual Basic COM Add-in that generated the benchmarks in Part 2, you'll find white papers on a variety of topics in application development.And, for those of you who've read Ken's Foreword: the Empire State Building has 6,500 windows (though I suspect that the number has been rounded), and the boiling point of bleach (typically, water with a 5% solution of NaOCI) is close to the boiling point of water at 212°F/100°C.