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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Distributing DLLs and Broken References 1

Status
Not open for further replies.

jwigal

Programmer
Mar 16, 2001
31
0
0
US
Hi--

I am attempting to distribute a MS Access database with InstallShield Express X. I intend to distribute vbSendMail.dll with the database.

I can get InstallShield to drop the DLL into a "common" folder, such as c:\windows\system32 or the like, so that the Access database will not miss a beat when the MDB is installed wherever and it looks for the DLL in c:\windows\system32, where it was installed on my PC during development.

My exprience has been with broken references is that, whenever there is a broken reference, the database will act very erratically, such as stopping on very basic VB functions and giving error messages or compile errors.

In most cases, as long as the end user has installed windows on the C-drive, this should not be an issue. I just want to try and proactively make sure that my user that has windows installed on d:\windows\ isn't going to have to plow through the VB code window to manually clear the broken reference.

I have seen the code to clear a broken reference, and set a reference using VB code. However, when I implement this, it never seems to intercept the problem fast enough before phantom error messages start popping up.

Any advice?

----------
Jeff Wigal
Referee Assistant for MS Access
 
Can't InstallShield register the DLL ?

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244
 
I have no experience at all with InstallShield, but instead of a hard path for the DLL, can't you specify an environment variable, like %systemroot%?

Ken S.
 
I'm sure it can. Is registering a DLL the same as setting the reference? (I'm pretty sure the answer is no, but i'll ask anyway)

If I develop with the reference set to c:\windows\system32, distribute the app, it installs on a D-drive and the DLL properly registers via InstallShield, will the reference "fix" itself?



----------
Jeff Wigal
Referee Assistant for MS Access
 
Eupher--

Can you set a reference in Access to a dynamic path like you suggest? I'm sure you can register a DLL/install to a dynamic path.

----------
Jeff Wigal
Referee Assistant for MS Access
 
Maybe I should clarify the program.

I develop on a C-drive. I tell InstallShield to install the DLL to %system32%

The end user installs, it drops the DLL into d:\windows\system32. The MDB opens up, looking for the DLL in c:\windows\system32 and then problems start happening.

----------
Jeff Wigal
Referee Assistant for MS Access
 
When you declare the DLL in Access set its path to:

Environ("SystemRoot") & "\"

In otherwords if your DLL is called MyDLL.DLL

in the Declare statement instead of using
"c:\windows\system32\myddl.dll"
use
Environ("SystemRoot") & "\system32\mydll.dll"

Hope this helps
 
earthandfire--

Right now I don't use a declare statement to use the DLL. I set a reference to the DLL under Tools -> References and just start using it. Once the reference is set, there are a number of functions, properties & events that become available.

is there a way to translate what is happening when I set the reference to one or more Declare statements?



----------
Jeff Wigal
Referee Assistant for MS Access
 
I'm not sure if this will do the trick or not but:

First, you need the "friendly" name of the library so, on your machine, run something like:

Code:
Dim ref As Reference
For Each ref In References
  Debug.Print ref.Name
Next

Male a note of the name of the reference of interest then
in the startup code in your database put something like:

Code:
Dim ref As Reference
If References("FriendlyName").IsBroken Then
  Set ref = References("FriendlyName")
  References.Remove ref
  References.AddFromFile (Environ("SystemRoot") & "\system32\mydll.dll"
)
End If

However, in theory, InstallShield should register the library, thus removing any problems.

Another thing worth trying would be to have a batch file start your program which runs regsvr first before loading the database.
 
It looks like that did it... I think what was causing the problem the last time is that I ran a routine that checked ALL references for broken references, and that may have caused Access to start poking around at other functions and raising other errors.

Thanks for your assistance!

----------
Jeff Wigal
Referee Assistant for MS Access
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top