• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 328
  • Last Modified:

sharing instance of dll

I have an ActiveX dll where two different projects have references to it. What needs to be done to allow the two projects to share one instance of the dll so as to share the underlying data within the dll too?

  • 3
  • 2
  • 2
  • +4
1 Solution
Well, you probably can't do it with a DLL.  A DLL is meant to run in the "process" of the calling program, so, all of the instance's variables are declared within the bounds of the caller.

To get two applications using one component to be able to share data in the component, the component needs to run "out of process".  The usual way of doing this is to turn your Active-X DLL into an Active-X EXE and give the instancing as Global Multi-Use (I believe).

Any global variables that you declare in the DLL should be available to any client who happens to be referencing the Active-X EXE.

Keep in mind, that if no clients have an instance open of the Active-X EXE, then I think that the EXE shuts down (but that might depend on in the instancing... and/or it might be something you can configure).
I would suggest using Stateful objects (Shared Property Manager, for example) to share the data within the dll. If either of the application that use the Dll component release the reference to the dll, the data will not be available to the other application. So the safest method would be to use stateful objects.
If you use the apartment threading model (set in project properties), anything you declare in a .bas module as Public will be shared between instances of your class.  This is regardless of whether you use a DLL (in process) or an EXE (out of process).

mdougan is almost right.  Each instance of your class will create it's own address space for it's own variables.  But this is only for variables declared as Private to the class.  Anything declared as Public in a .bas module will be shared.

The public data will remain available as long as there is at least one reference to a class in the DLL.  If there are no references (ie. all of your references have been set to =Nothing)  the DLL is unloaded and the data is destroyed.
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Anthony PerkinsCommented:
Please post a message to Community Support to delete your following open questions:
Retrieving the processes of all Excel applications Date: 02/04/2002 08:56AM PST
Manipulating folder permissions Date: 09/07/2001 10:06AM PST
Left, Top properties of form Date: 08/09/2001 01:20PM PST
Accessing the call stack Date: 07/05/2001 12:54PM PST
Free membership ISP's Date: 07/09/2001 03:31PM PST  


admittedly, I am probably wrong about this, but my understanding is that regardless of your threading model, any storage allocated in a DLL is going to be restricted to the process that spawned the DLL.  

Now, if a single project spawns multiple instances of the class in the DLL, I'd agree with you, that those instances could share public variables, because they are all running under the same process.  

However, I would stop short of saying that two separate executables, running in their own processes, instantiating their own instances of a class in a DLL would be able to share public variables.
What is to feel humbled....

Your right.  I just did some tests.  They are only "public" if instances of the class are started in the same executable.  If they are in different executables, the Public vars are only public to the current exe instance.

cartti: Ignore me and listen to a real expert <sigh>
carttiAuthor Commented:
Having done some tests, it doesn't seem to be possible. What I've done is to merge both projects so they use the same dll. It's not ideal, but theoretically it should have been done that way in the first place.

Unless anyone can come up with a solution, I'll delete the question.

Thanks for your contributions.
Well, again, converting the DLL to an EXE will do what it is you wanted to do.  I'm not sure why you would choose to merge your two projects and not simply change the project type of your component to Active-X EXE

But, if that's out of the question, then go ahead and delete the question.
carttiAuthor Commented:

The ActiveX exe technique didn't work either.

Hi cartti,
It appears that you have forgotten this question. I will ask Community Support to close it unless you finalize it within 7 days. I will ask a Community Support Moderator to:

    Accept mdougan's comment(s) as an answer.

cartti, if you think your question was not answered at all or if you need help, just post a new comment here; Community Support will help you.  DO NOT accept this comment as an answer.

EXPERTS: If you disagree with that recommendation, please post an explanatory comment.
DanRollins -- EE database cleanup volunteer
per recommendation

Community Support Moderator @Experts Exchange
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 3
  • 2
  • 2
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now