asked on

ActiveX DLL - separate instances of linked library

I've got a VB ActiveX object which links to a separate DLL (VC++ based). When I create multiple instances of the ActiveX object from within the same program, I get true, separate instances (all the properties are separate, as they should be). However, I really need the DLL that I'm linking to also be truly separate instances of that DLL but I can tell they are not (based on values stored by the DLL)

Internal to my VB Class, I've got:

' "mycall" is an entry point in mycpp.dll
Private Declare Function mymath Lib "mycpp.dll" Alias "mymath" (ByVal info As String) _
     As Long

' the public version to access that library
Public Function doMath(ByVal info As String) As Long
    doMath = mymath(info)
End Function

' and a property...
Private myInternalProp As String
Public Property Let someProp(value As String)
    myInternalProp= value
End Property
Public Property Get someProp() As String
    someProp = myInternalProp
End Property

Open in new window

If I then instance two copies of this object from a separate VB application (for example)

Dim obj1 As myTools.application
Dim obj2 As myTools.application
Set obj1 = New myTools.application
Set obj2 = New myTools.application

obj1.someProp = "first instance"
MsgBox(obj2.someProp)  'shows empty, thus unique copy of "application"
result1 = obj1.doMath("...")
result2 = obj2.doMath("")    'result2 shows that this called into the same DLL

Open in new window

The "someProp" value is clearly separate between the two objects, but the doMath is calling the SAME instance of the DLL (the DLL saves some values and I can tell from the output of "domath" that it is the same call)

However, if I split obj1 and obj2 and their corresponding calls into two separate VB applications, they are completely separate (doMath clearly calls a separate .dll copy)

Is there some way from the VB side to force each instance of the ActiveX accesses a different copy of the mycpp.dll?

jkr

I think there is some confusion about that 'separate instance/copy' issues. Any DLL on Windows (ActiveX or not) is mapped into memory only once, just different data sections are created for each process that is using it. If the DLL in question however is programmed to share a certain data segmants among the processes that are using it (see e.g. http://support.microsoft.com/kb/100634 - "How to specify both shared data and non-shared data in a DLL in Visual C++") there's ahardly anything you can do about it frm the VB side if you don't have the source code. If this wasn't an ActiveX DLL, you might be able to create a workaround using different physical copyies of the same file and loading them with absolute paths, but since ActiveX DLLs are loaded via COM, that will not work.

jersa

ASKER

Well, to say that it is mapped only once is a bit misleading, isn't it? Because I know that if we split the code so that we have two separate applications, each of which is accessing this ActiveX they behave exactly as we want (they each access a "pure" copy of the C++DLL). So, it is mapped into memory only once PER APPLICATION, right? Each application gets its own copy of the DLL.

ASKER CERTIFIED SOLUTION

jkr

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

jersa

ASKER

After further investigation, it turns out it isn't the C++DLL itself that is sharing data between process boundaries, but something below that.

In other words, it not only isn't my activeX that has the problem, but it is the C++ DLL that has the problem and it isn't the fault of (nor anything that can be fixed by) that DLL either.

Thanks for the confirmation that I'm not going crazy.

jersa

ASKER

The information was accurate and helped clarify that the problem was more complicated than it appeared and couldn't be solved without significant revision.