VB Helper_ HowTo_ Make an ActiveX DLL or EXE

HomeSearch

What's New

IndexBooksLinksQ & A

NewsletterBanners

FeedbackTip Jar

C#Helper...

MSDN Visual

Basic Community

Title Make an ActiveX DLL or EXEDescriptionKeywords ActiveX DLL, ActiveX EXECategories ActiveX

Why?Which?Making an ActiveX DLL/EXE ProjectInstancing

PrivatePublicNotCreatableSingleUseGlobalSingleUseMultiUseGlobalMultiUse

Test ProjectsBinding

Early BindingLate Binding

Why?

You make an ActiveX DLL or EXE to allow multiple applications toshare the same code. This saves you time because you only need to writethe code once. It also lets you devote extra time to debugging the sharedcode. 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 andstill save time overall.

Centralizing the code also lets you fix, upgrade, and otherwise modify theshared library relatively easily. You can update the shared DLL/EXE andall of the applications that use it are automatically updated. The Bindingsection talks more about this.

Which?

ActiveX DLLs and ActiveX EXEs are almost exactly the same in theways they are built and used. In both cases, you build one or more classesthat applications can use to do something. The big difference lies inwhere they are used.

An ActiveX DLL's code is executed within the main program's addressspace. It behaves as if the class was created within the main program'scode. Because the code lies inside the program's address space, callingmethods is very fast.

An ActiveX EXE's code is run in a separate process. When the mainprogram calls an ActiveX EXE's method, the system marshalls the call to

VB Helper: HowTo: Make an ActiveX DLL or EXE http://www.vb-helper.com/howto_activex_dll.html

1 of 6 07-Jun-11 11:44 PM

translate the parameters into the ActiveX EXE's address space, calls themethod, translates the results back into the main program's address space,and returns the result. This is slower than running an ActiveX DLL'smethod inside the main program's address space.

Because of the difference in speed, an ActiveX DLL is almost alwayspreferable. The reason ActiveX EXEs are useful is they can run on adifferent computer than the main program while an ActiveX DLL mustrun on the same computer as the main program.

If you want to build a library of shared routines to save programming anddebugging, use an ActiveX DLL because it will give you betterperformance. Even if you need to distribute several copies of the DLL ondifferent computers, it will probably be worthwhile.

If you want a centralized server library, use an ActiveX EXE. The EXEcan sit on a central computer and work directly with that computer'sresources. If you need to frequently change how the code works, you caneasily change it in one place.

Making an ActiveX DLL/EXE Project

Start a new project and select ActiveX EXE or ActiveX DLL. Initiallythe project is named Project1 and contains a class named Class1. Changethese to meaningful names. The model Microsoft has in mind is aDLL/EXE contains several related classes that each perform relatedfunctions. For example, a DLL might contain billing system classesnamed Customer, Product, and SalesPerson. The Customer class wouldcontain methods for manipulating customer data. In this example, youmight change the project name to BillingObjects. You would changeClass1's name to Customer and add two more classes named Product andSalesPerson.

Give the class Public functions and methods to perform whatever tasks itshould. The main program can only invoke the Public class methods.

Instancing

Set the classes' Instancing properties to determine how the object can becreated. In VB6 the allowed values are:

Private

Code outside the DLL/EXE cannot create this object type. Other classesin the DLL/EXE can use this type of class as a helper but the mainprogram cannot use it.

PublicNotCreatable

The main program can use this type of class but cannot create newinstances using the New keyword or with CreateObject. In this case, youneed to provide some method within the other classes to create the newobject and return it to the main program.


2 of 6 07-Jun-11 11:44 PM

SingleUse

The main program can create the object. Every time you create a newobject, the system makes a new ActiveX EXE instance to service theobject you created. Among other things, if the EXE contains globalvariables then different objects you create get different copies of thevariables. This option is allowed for ActiveX EXEs only.

GlobalSingleUse

Similar to SingleUse except you can invoke the properties and methods ofthe class as if they were simple global functions. This option is allowedfor ActiveX EXEs only. See GlobalMultiUse later for more details.

MultiUse

The main program can create the object. When it does, the system makesan ActiveX DLL/EXE component to handle the object. If you makeother objects, the system uses the same ActiveX DLL/EXE component tohandle them. This can be a little confusing depending on whether you arebuilding a DLL or EXE and whether an EXE is running on differentcomputers.

If you build an ActiveX DLL, all programs run the DLL code in theirown address spaces. That means different objects created in the sameprogram will share the same component server so they could share globalvariables defined in the DLL. However, if the objects are all freed at thesame time, the component server will shut down so any global values willbe lost.

The code in the SharedDll directory available for download demonstratesthis kind of sharing. The BillingObjects,vbp project contains the projectnamed BillingObjects. This project holds a BAS module holding a publicvariable named g_TheNumber. This variable is visible to other code inthe project but not to a main program using the DLL.

The BillingObjects project also contains a MultiUse class namedCustomer. This class has Property Let and Property Get procedures thatset and get the value of g_TheNumber.

The main program uses two Customer objects like this: Private m_Customer1 As ObjectPrivate m_Customer2 As Object

Private Sub Form_Load() Set m_Customer1 = _ CreateObject("BillingObjects.Customer") Set m_Customer2 = _ CreateObject("BillingObjects.Customer")End Sub

Private Sub cmdGet_Click() txtTheNumber.Text = m_Customer1.TheNumberEnd Sub

Private Sub cmdSet_Click() m_Customer1.TheNumber = CInt(txtTheNumber.Text)


3 of 6 07-Jun-11 11:44 PM

txtTheNumber.Text = ""End Sub

In the DLL project, open the File menu and select MakeBillingObjects.dll to build the DLL. Notice how the main program usesthe CreateObject function to create its instances of the Customer class.The name of the class is the project's name followed by the class name:BillingObjects.Customer.

Notice also that the program creates the two Customer objects when itstarts and it keeps those objects running. That means the component staysrunning so the objects share the value of g_TheNumber. If you use theSet button to save a value into this variable and then use the Get buttonto retrieve the value, you should get back the value you saved.

This behavior is what you would expect if you included the DLL'smodules directly inside the main program. If you want that behavior,make the DLL MultiUse. If you want each class object to have its ownglobal variables, make the DLL SingleUse. Or better still, move thevariables inside the class so each object gets its own variables but youstill only need one component instance. That will save some overhead.

Now you're probably saying, "Big deal. I could have shared values a lotmore easily with simple global variables." You're right. The interestingthing is any program that uses a shared component server can share thevalues. Compile the test program and use Windows Explorer to launchtwo instances of the program. Enter 1234 in one instance and click Set.Then click Get in the other instance. The second program should see thevalue set by the first.

Note that this sometimes gets messed up and a component server is leftrunning so you may end up with two programs running differentcomponent servers.

The ActiveX EXE project in the SharedExe directory demonstrates thissharing using an ActiveX EXE. It's basically the same as the previousexample except is uses an ActiveX EXE instead of a DLL. Compile thetest program and use Windows Explorer to launch two instances of theprogram. Enter 1234 in one instance and click Set. Then click Get in theother instance. The second program should see the value set by the first.

GlobalMultiUse

This is similar to MultiUser except the main program can referencemethods and properties as if they were globally declared. The code in theGlobalMultiUse directory demonstrates this. The ActiveX EXE code isthe same as in the previous example except the Customer class is markedGlobalMultiUse. The main program uses the Customer's TheNumberproperty procedures like this: Private Sub cmdGet_Click() ' Implicit use of: ' GlobalBillingObjects.Customer.TheNumber txtTheNumber.Text = TheNumberEnd Sub

Private Sub cmdSet_Click() ' Implicit use of:


4 of 6 07-Jun-11 11:44 PM

' GlobalBillingObjects.Customer.TheNumber TheNumber = CInt(txtTheNumber.Text) txtTheNumber.Text = ""End Sub

This code simply uses the TheNumber procedures as if they were globallydeclared. When the program invokes one of the methods using this globalsyntax, it creates an instance of the class to use its methods. It continuesto use that instance whenever it needs to execute a global method.

If you explicitly create other instances of the class, you get new objectnot the global one. As far as I know, there is no way to get a directreference to the global object instance.

This all seems pretty confusing so I would avoid using GlobalMultiUseand GlobalSingleUse. They let you use a syntax that is more similar tothat used by DLLs built in C++ and other languages and that's probablywhy Microsoft implemented these. They hide the fact that there is anunderlying class object, however, so they increase your chances forconfusion.

Test Projects

The previous sections glossed over a few details dealing with testprojects. After you create your ActiveX DLL project, you can add a testapplication. Open the File menu, select Add Project, and add a StandardEXE. That project can act as the main program to test your DLL. This ishandy because it means you don't need to compile the DLL before youcan test it. It also means you don't need to jump back and forth betweenthe DLL and test application projects.

After you have the DLL code working, you can compile it into a DLLfile. Then you can create independent applications to use it.

Binding

You can bind your DLL or EXE either at runtime (late binding) or atdesign time (early binding). When you use early binding, you tell themain program all about the DLL. That lets it do things like provideintellisense for the DLL's methods. It is also faster than late binding.

Early Binding

To use early binding, load the main program, open the Project menu, andselect References. Find your DLL in the list and select it. If the DLLproject's name is BillingObjects, then look for an entry namedBillingObjects. If you have had a couple versions of the project indifferent locations, you may see more than one entry. Click on one andlook at the location displayed near the bottom of the dialog to see if youhave the right one. If you can't figure it out, click the Browse button andfind the DLL yourself. When you have selected the DLL, click OK.

Now the program can explicitly refer to the classes in the DLL. Forexample, it could declare and create a Customer object like this:


5 of 6 07-Jun-11 11:44 PM

Dim customer1 As Customer Set customer1 = New Customer

If you now type "customer1.", intellisense will be able to list the publicmethods provided by the Customer class. In this example, this is just theTheNumber property procedure.

Early binding has the disadvantage that it imposes more restrictions onthe DLL's compatibility. If you change the DLL's methods as they arevisible to outside code, the main program will no longer have a correctpicture of the DLL. For example, if you add a new Public method to aclass, the main program will not know about that method. When you tryto create an instance of the class, the system will decide that the programis looking for an incompatible DLL version and will display the message:

Class does not support Automation or does not supportexpected interface

To fix this, load the main program, open the Project menu, and selectReferences. Deselect the DLL and click OK. Then open the Referencesdialog again and reselect the DLL. Now the program will work again.

Depending on your exact arrangement, you may also get the error:

Type mismatch

To fix this, recompile the main program.

Late Binding

To use late binding, declare references to DLL objects to have typeObject. Then use the CreateObject statement to instantiate the objectslike this:

Dim customer1 As Object Set customer1 = CreateObject("BillingObjects.Customer")

This code creates an instance of the Customers class that is defined bythe DLL project named BillingObjects. After this the program can use thePublic properties and methods of the customer1 object just as if it haddeclared it using early binding.

Now if you change the DLL's public methods, the compiled executablewill still work (if you removed the methods the program uses). Thedownside with late binding is you don't get intellisense and calling theDLL's methods takes longer than it does with early binding.

Copyright © 1997-2010 Rocky Mountain Computer Consulting, Inc. All rights reserved.

http://www.vb-helper.com/howto_activex_dll.html Updated 11/11/2010 00:35:19


6 of 6 07-Jun-11 11:44 PM

Documents

VB Helper_ HowTo_ Make an ActiveX DLL or EXE