In the previous edition of this book, I provided a DLL written in C and a bunch of Visual Basic modules. Even if you never read the book, you could use any of the modules or the DLL in your own projects. But providing source code isn’t exactly code reuse in the classic sense. And providing a DLL written in another language doesn’t give you too many customization options if you don’t know the other language. So this time I’m doing it differently.
First, everything is in Basic. All the procedures provided in the C DLL last time have been rewritten in Visual Basic. You might lose a few microseconds on some of these procedures because C can be a faster language than Basic. But if you compile to native code, I don’t think you’ll notice. And normally you will use the native code version because all the general-use procedures and classes that were provided as separate modules in the first edition are now provided in a component called VBCore.
The programming model used throughout most of this book is that your programming tools go in the component—in most cases VBCore, but sometimes in other components. The components are compiled to native code with as much optimization as their features will stand. The VBCore component is kind of big—about 580 KB—and you do have to ship it to customers. But if you put all your speed-critical code in the core, you can use p-code in the main program and get smaller programs. Or you can compile the main program too, if you prefer.
Using a component instead of modules has its pluses and minuses, but I’d say the positive side of the scale outweighs the negative. For example, I frequently encountered a problem that must have driven users of my book crazy. Let’s say I’m writing a program that needs to work on Widgets. Widgets.Bas has the very function I need, but when I add it to my project, it turns out that the module uses Sockets.Bas. And Sockets.Bas requires Clamps.Bas, which requires some other module. That problem disappears with VBCore. You get everything you need from one component. Sure, it’s larger than the individual modules. You might end up with some stuff you don’t need, but that’s only on the disk. The modules in the component don’t get into memory unless a program uses them. Furthermore, many programs can share the same component.
There is a downside. If your customer has only one program that uses the component, code sharing is wasted. Furthermore, although you have access to the source code for the component, you can’t just go changing it willy-nilly. This is a published COM component after all, and the whole idea of COM starts to fall apart if everyone feels free to modify other people’s components. In fact, if I find people modifying my code and sending it to customers with the name VBCore, I’m going to be more than a little peeved. What happens if Hardcore programmer A modifies VBCore and sends it to a customer, but that customer also buys a product from Hardcore programmer B who has also modified VBCore—and then I sell that customer another program that uses the original VBCore? Sending out the source code to a component (as I’m doing with this book) is a pretty dangerous thing. Don’t try this at home.
But you do have an out. You don’t have to use the component. You can use each of the modules in the source files directly in your program without the component. You can cut out any of my code and paste it into your code. You can create your own new component that uses my modules, but you must rename any public modules. In other words, you bought the code with the book. It’s yours. (Curses on anyone who uses my code without buying my book!) But the component is mine. You bought the right to use it, but you have no right to change it. If you find that one (and only one) bug that I put in VBCore to keep you on your toes, send me a bug report. I’ll fix VBCore and post a new version on my Web site (with credit to you, of course).
VBCore consists of three things: classes, global procedures, and global objects. There’s not much to say about adding classes to a component, but adding global procedures and global objects can be difficult. We’ll look at them next.