Avatar of jersa
jersa 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?
Visual Basic ClassicC++Programming Theory

Avatar of undefined
Last Comment

8/22/2022 - Mon

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.

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.

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question

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.
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck

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