Setting References with VBA - Custom Location of DLL

[microb0x]

During the startup of my application I am setting a reference to the
Word 11.0 library and Office 11.0 library. I am pointing to DLL's that
are in a custom folder for my app, and not the common folder where
these usually reside.

The problem I'm having is when I go into the VBA editor and check the
references, although both of the libraries are listed as being
referenced; the location listed at the bottom of the references window
still shows the original path and not the custom path I have specified.

For Instance:

With the Microsoft Office 11.0 Library

Its default path is:

C:\Program Files\Common Files\Microsoft Shared\OFFICE11\MSO.DLL

the path I'm setting a reference to via code is:

C:\Program Files\Underwriting Authority\DLLs\MSO.DLL

Underwriting Authority of course being the name of my app and the
folder containing the front end.

The code I'm using to set the reference is as follows:

Application.References.AddFromFile (vDLLPath & "MSO.DLL")

vDLLPath is a string variable containing the path to my DLLs folder.


Can anyone shed any light on why it still shows the original path and
not my custom path in the VBA Editor? I would really appreciate this.
I have been having a hard time with references, adding/removing via VBA

 

[Albert D. Kallal]

You can't even begin to expect any degrees of reliability if you ship your
application with references.

For word, outlook etc, I stopped trying to make references work about 7
years ago, and that was about 1 week after using ms-access.

It is JUST NOT workable, and every developer after about a week or so will
start reading up on this, and everyone on planet earth will tell your the
same thing:

You REALLY REALLY REALLY need to use late binding for your automaton code.

This concept is explained here:

http://www.granite.ab.ca/access/latebinding.htm

So, remove those word, and other references.

for your custom .dll's, simply load them at runtime

Private Declare Function LoadLibrary Lib "kernel32" _
Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long

Private Declare Function FreeLibrary Lib "kernel32" _
(ByVal hLibModule As Long) As Long


And, in your code, before you use any dlls calls, just load the lib as
follows:

dim lngRef as long

lngRef = LoadLibrary("string path name to your dll...this can be relative to
the mde/mdb running path")

So, for outlook, word etc, use late binding. For your custom dll's, DO NOT
bother to register them, but simply use the load library as above. This
approach means that you just copy the folder with your mdb (or preferably
mde) and the folder with the dlls in it to another machine..and it simply
works....

You can also use the freelibary api to un-load the dll's, but I generally
don't bother.

So, late binding means that a update to word, or outlook will NOT break your
code. It means if they run a different version of outlook, you code WILL
STILL likely run. and, futher, if they don't have one of the libraries, (so,
they have word, but not outlook), your code can STILL WELL function without
a breakage. And, as mentioned, the loadlibary means you don't have to
register your dll's.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)

..

 

[microb0x]

Thanks much for the expert advice!

You can't even begin to expect any degrees of reliability if you ship your
application with references.

For word, outlook etc, I stopped trying to make references work about 7
years ago, and that was about 1 week after using ms-access.

It is JUST NOT workable, and every developer after about a week or so will
start reading up on this, and everyone on planet earth will tell your the
same thing:

You REALLY REALLY REALLY need to use late binding for your automaton code.

This concept is explained here:

http://www.granite.ab.ca/access/latebinding.htm

So, remove those word, and other references.

for your custom .dll's, simply load them at runtime

Private Declare Function LoadLibrary Lib "kernel32" _
Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long

Private Declare Function FreeLibrary Lib "kernel32" _
(ByVal hLibModule As Long) As Long


And, in your code, before you use any dlls calls, just load the lib as
follows:

dim lngRef as long

lngRef = LoadLibrary("string path name to your dll...this can be relative to
the mde/mdb running path")

So, for outlook, word etc, use late binding. For your custom dll's, DO NOT
bother to register them, but simply use the load library as above. This
approach means that you just copy the folder with your mdb (or preferably
mde) and the folder with the dlls in it to another machine..and it simply
works....

You can also use the freelibary api to un-load the dll's, but I generally
don't bother.

So, late binding means that a update to word, or outlook will NOT break your
code. It means if they run a different version of outlook, you code WILL
STILL likely run. and, futher, if they don't have one of the libraries, (so,
they have word, but not outlook), your code can STILL WELL function without
a breakage. And, as mentioned, the loadlibary means you don't have to
register your dll's.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)

.