Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

What is difference between open dll and referenced dll? 1

Status
Not open for further replies.

rvr

Programmer
Jan 26, 2000
16
ZA
Hi,

What is the difference between a dll project open in VB when the application that reference it is run, and the referenced dll that is only referenced from the application that is run, and not open as project in VB?

I have a application that reference a dll created by me. When I open the application in VB and run it, referencing the dll, but the dll is not loaded (open) in VB, I get different results than when I open the application and the dll in VB and run it then. What is the difference?
 
When you instantiate a copy of a ActiveX DLL, VB checks the registry to try and find where to go get a copy of it. The trick is when you have a source-code copy of your DLL running in another copy of VB. When that project is run, it changes that registry entry to point to itself, rather than the DLL in the filesystem. When you end the DLL project, it changes the registry entry back to point at the filesystem DLL (i.e. C:\MyDLLProject\MyDLL.dll)

The differences you're seeing could be because the version in the directory, and the version loaded up in VB have significant differences in functionality.

Another possibility is that when you do make significant changes to the public "image" of an Active-X object, COM then assumes that you've created a new release, and will track the two separately. To avoid this, make sure that you use "Binary Compatability" in your project's build settings. VB will then warn you when you make changes to your code (change a return type from a function, change the interface to a subroutine, change a name of a function or class, etc).

Chip H.
 
Hi,

Thanks for looking at my question.

I checked the dll, but the binary compatibility is set. Where in the registry is the paths of the dll's? I would like to check that as well. What I do, is to open the dll, test it (then it is working), 'make' the dll to its directory, make sure the application's reference show to that dll, and when I run it again it is not working (no changes in functionality). I thought that the latest dll you made would be the one which path is placed in the registry.

It seems as though the dll is loaded twice, and the first one sets a variable in the dll, but the sencond instance resets it again, so that it appears that the program is not working. The dll is marked as apartment threaded, I don't know if that could have something to do with it...

Do you perhaps have any more ideas on this which I could try? Thanks for the help this far. I am starting to understand how dll's work!

Regards,
 
To find where the registry is loaded your ActiveX DLL, search through HKEY_CLASSES_ROOT for the name of your project and class (It'll look like: MyProject.MyClass). Underneath that is a CLSID key. Look for that CLSID under: HKEY_CLASSES_ROOT\CLSID. Underneath that key you'll see a key called "InprocServer32", and it's default value points to the DLL.

Also, what order are you running your two projects? You need to run your DLL project in debug first, before running the project that references. Don't be too fast, too. VB can take a while to swap the references. So start the DLL project, wait 10 seconds, then start the other project.

Chip H.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top