Functional DLLs


The DLLs in Visual Basic version 4 were a useful feature, but some programmers wanted more. They wanted to put functions in DLLs, just as you can do with most other languages that support DLLs. Visual Basic seemed to be split into two different worlds. In programs, object-oriented programming was voluntary. In DLLs, it was mandatory. If you wanted to put ordinary procedures in a DLL, well, you could write that DLL in some other language.


If you looked in the Object Browser, you could see that Visual Basic itself wasn’t playing by the same rules. It had the Visual Basic Objects and Procedures li­­-
brary and the Visual Basic for Applications library. Somebody was writing DLLs containing both procedures and classes in some language. Why couldn’t that language be Visual Basic? This is a familiar story. Visual Basic used optional
arguments, controls, properties on forms, and who knows what else before it let us use them. But eventually it lets us play ball.


Visual Basic version 5 lets you put procedures in DLLs, but the feature isn’t as simple as you might hope. Something strange is going on behind the scenes. You can see it in the Object Browser. Sure, it looks like FileLen is a function in the Visual Basic for Applications library. You can use FileLen as if it were a function. But it’s not. It’s a method of the VBA object. Anytime you want to use FileLen, you have a choice. You can say this:

cFile = VBA.FileLen(sFile)

Or you can say this:

cFile = FileLen(sFile)

It’s a pretty obvious choice in most cases, although the sidebar “Better Basic Through Subclassing” describes a situation where you want to qualify library procedures. The VBA object is kind of a default object—comparable to a default property. You can leave off the object name just as you can leave off the property name of a default property. Visual Basic instantiates the VBA object for you, and you can pretend it doesn’t exist.


The secret to putting procedures in a DLL is that you write them as methods of what Visual Basic calls a global object. We’re now ready to write a library called VBCore, based on global objects.