You make an ActiveX DLL or EXE to allow multiple applications to share the same code. This saves you time because you only need to write the code once. It also lets you devote extra time to debugging the shared code. If you are going to use the code in a lot of different applications, you can perform extra tests to make sure the code works correctly and still save time overall.
Centralizing the code also lets you fix, upgrade, and otherwise modify the shared library relatively easily. You can update the shared DLL/EXE and all of the applications that use it are automatically updated. The Binding section talks more about this.
ActiveX DLLs and ActiveX EXEs are almost exactly the same in the ways they are built and used. In both cases, you build one or more classes that applications can use to do something. The big difference lies in where they are used.
An ActiveX DLL's code is executed within the main program's address space. It behaves as if the class was created within the main program's code. Because the code lies inside the program's address space, calling methods is very fast.
An ActiveX EXE's code is run in a separate process. When the main program calls an ActiveX EXE's method, the system marshalls the call to translate the parameters into the ActiveX EXE's address space, calls the method, translates the results back into the main program's address space, and returns the result. This is slower than running an ActiveX DLL's method inside the main program's address space.
Because of the difference in speed, an ActiveX DLL is almost always preferable. The reason ActiveX EXEs are useful is they can run on a different computer than the main program while an ActiveX DLL must run on the same computer as the main program.
If you want to build a library of shared routines to save programming and debugging, use an ActiveX DLL because it will give you better performance. Even if you need to distribute several copies of the DLL on different computers, it will probably be worthwhile.
If you want a centralized server library, use an ActiveX EXE. The EXE can sit on a central computer and work directly with that computer's resources. If you need to frequently change how the code works, you can easily change it in one place.
Start a new project and select ActiveX EXE or ActiveX DLL. Initially the project is named Project1 and contains a class named Class1. Change these to meaningful names. The model Microsoft has in mind is a DLL/EXE contains several related classes that each perform related functions. For example, a DLL might contain billing system classes named Customer, Product, and SalesPerson. The Customer class would contain methods for manipulating customer data. In this example, you might change the project name to BillingObjects. You would change Class1's name to Customer and add two more classes named Product and SalesPerson.
Give the class Public functions and methods to perform whatever tasks it should. The main program can only invoke the Public class methods.
Set the classes' Instancing properties to determine how the object can be created. In VB6 the allowed values are:
Code outside the DLL/EXE cannot create this object type. Other classes in the DLL/EXE can use this type of class as a helper but the main program cannot use it.
The main program can use this type of class but cannot create new instances using the New keyword or with CreateObject. In this case, you need to provide some method within the other classes to create the new object and return it to the main program.
The main program can create the object. Every time you create a new object, the system makes a new ActiveX EXE instance to service the object you created. Among other things, if the EXE contains global variables then different objects you create get different copies of the variables. This option is allowed for ActiveX EXEs only.
Similar to SingleUse except you can invoke the properties and methods of the class as if they were simple global functions. This option is allowed for ActiveX EXEs only. See GlobalMultiUse later for more details.
The main program can create the object. When it does, the system makes an ActiveX DLL/EXE component to handle the object. If you make other objects, the system uses the same ActiveX DLL/EXE component to handle them. This can be a little confusing depending on whether you are building a DLL or EXE and whether an EXE is running on different computers.
If you build an ActiveX DLL, all programs run the DLL code in their own address spaces. That means different objects created in the same program will share the same component server so they could share global variables defined in the DLL. However, if the objects are all freed at the same time, the component server will shut down so any global values will be lost.
The code in the SharedDll directory available for download demonstrates this kind of sharing. The BillingObjects,vbp project contains the project named BillingObjects. This project holds a BAS module holding a public variable named g_TheNumber. This variable is visible to other code in the project but not to a main program using the DLL.
The BillingObjects project also contains a MultiUse class named Customer. This class has Property Let and Property Get procedures that set and get the value of g_TheNumber.
The main program uses two Customer objects like this: