How to reference a Dll at runtime

Are these dll's interchangable - have the same functions etc that you will be using. It may be possible to accomplish this with COM & Type Libraries (.tlb).

Unfortunately, VB doesn't have a method for dynamically binding to a type library at run-time (at least not that I'm aware of). Alas, this would be nice, but for now you may have to relegate yourself to creating a generic interface to the DLLs for run-time binding.

Wizard2 is right,
you can not reference a DLLduring runtime.
In a compiled EXE, VB builds himself a list of available resources, which can be
seen in the object explorer.

You MUST add these references before you compile a project.

I´ll give more details on the use of the Dll so you can propose an alternate answer.
The Dll's identify a group of objects wich share some common characteristics. Each Dll has the information for creating some objects like apearance and behabior. The problem is that I want to distribute the final application with only some basic objects. If the user needs extra objects he buys them and just copy the Dll (wich contains the extra objects) in a directory so when the program starts it recognizes the added Dll.

I´ve seen other programs behave like that i.e. MathLab.

Since it´s becomming more dificult than I first thought I´ll increase 50 points to the question.

As far as VB goes, you simply can NOT do that.
I know it isn't a pleasant answer.

But I would suggest making a small DLL to demonstate
and if the user wants to purchase send him the new DLL
with the same Binary Comp.

Wizard2 is right: see http://premium.microsoft.com/msdn/library/books/techlang/hcvb/html/loadingmodule.htm. Could get around it by using a little C DLL function to dynamically bind at runtime (why not just use some form of licensing and distribute a single DLL)

I found a way but is ineficient. IF the Dll is in the registry of the system I CAN use it with the function CreateObject but Vb loads some error handlers and routines that slow down my app performance. This type of declaration is knokn as late binding. I was told that in Vb6 there wasn´t this slow down problem but i only have Vb5.

You can create all the dll's in advance and add them to your project references. Then you can write code that uses your objects with one precaution - you must check for the dll's existance before dimming any variables as a type that might not be included. For instance, if you plan on putting the dll's in the same directory as the exe then you could write code that looks like this:

Public Sub UseMyDogObject()

If filelen(App.path & "\Dog.dll") <> 0 then
   ReallyUseDogObject
Else
   MsgBox "You must purchase the dog object from me."
End IF

End Sub

Public Sub ReallyUseDogObject()
   Dim oDog As Dog
   Set oDog = New Dog
   MsgBox Dog.Bark
   MsgBox "Etc..."
   set oDog = Nothing
End Sub

[-Note- this will not compile correctly if the dll's do not exist but if you compile this and then remove some dll's it will just not use the objects from the dll]

The fast solution is to define an interface that all the DLL should support. This interface is just a public class in what might be a seperate DLL.
Every DLL should now implement this interface using the keyword implements.

Implements IMyDLLInterface

In the calling exe you can now create the object using create object and assign it to an IMyDLLInterface object

Dim dllInstance as IMyDLLInstance
set  dllInstance  = CreateObject ("Proj.Class")

Now it is early binding again.

Hi Mirkwood, I already tried your aproach in Vb5 and this is what hapened: Vb ctreated the object and killed it before reference it to the variable (dllInstance in your example) but this is the closest I´ve been. I don't know if is the same situation in Vb6.

Is there any way to do it in C++ and try to use it in visual?.

vbwhiz, your solution is very good but I can´t plan the objects that are going to be added in the future. I was thinking of a special module in all the Dll that tell the program which object are available in the Dll. Both of you are very close.

javierma, how about having an intermediate dll that contains code like my dog example. This dll would have only one class that can then create instances of the other classes from the other dlls. You could then recompile a new version of this small intermediate dll every time you create some new objects and send it along with the new dll.

We use it with VB5 and it works fine.
I would try it again if I were you because this definitelly works.