Installing References Automatically 2

[DISI]

I have an application that I am distributing. The problem is that it uses a number of References that are not "Typically" installed during MS Office installation.

I know that when I have worked on my user's PC, I've had to do "Custom" installation of MS Access and select every option available. My application references the following:

Visual Basic For Applications
Microsoft Access 9.0 Object Library
OLE Automation
Microsoft DAO 3.6 Object Library
Microsoft Visual Basic for Applications Extensibility 5.0

My users are not Access savy and I don't want them to have to go into Access VB code to check references.

1. Is there a way to automatically install these files from my CD and reference them in my application?

2. If not, how can I tell which options to install during set up that will get me the references listed above?

Appreciate the help. Mind you, I am not a whiz at VBA so I'll need very specific instructions on how to use recommended code. Thanks

DISI
Paul Faculjak
paul@DataIntegritySolutions.com

 

[JimHorton]

There is a way to do this...(It's in access help, you can look it up for more detailed info)
dim ref as reference
Set ref = References.AddFromFile("C:\Windows\System\SomeDLL.dll&quot
You don't need to do anything with Ref, it's added with the AddFromFile method
--Jim

 

[BoxHead]

Paul, Good question.

Jim, Great Answer!

Thanks,

John

 

[DISI]

Jim,

Too Cool!! I got this to work. Thanks so VERY MUCH

Question, do the dll files NEED to be located in a specific sub-directory? Most systems will be running NT, but no guarantee. Can I just copy the dll files into my own sub-directory which is created with the installation of my application and reference them?

Paul Paul Faculjak
paul@DataIntegritySolutions.com

 

[JimHorton]

Paul,
When the dll's or ocx's were originally installed, (with the vb install or some other install) a registry entry was given that points to the directory where they exist. If the file you reference is in a different location, but the same file, you may be ok, but if it happens to be an older version, I think you could have problems. If the file isn't where you expect it, you could re-register in code using regsvr32 [ddl or ocx path and name].

So it's best to look for the file in code to be sure it exists in the location where you'll set the reference. Offhand, in Access, I can't think of a super efficient way to do that, without a directory list object, I guess you could try using one of the file commands like Filedatetime or something, and trap for an error, if not found, look in the usual other places, if not there, bring up a File Dialog and have the user find it. In VB it would be easier, with richer file/directory objects.
--Jim

 

[DISI]

Jim,

You read my mind. I was going to next ask about having to use regsvr32. From your last post I am assuming I DO need to use regsvr32 if the files were not "installed". Setting the references in Access is only pointing Access to the files, not "activating" them if they are new. Correct?

Given my minimal mastery of VBA I guess the best thing to do is install the files with my application and instruct the user to use regsvr32 regardless. Then I will set references upon loading, pointing to my sub-directory with the dll's. Not pretty, but it makes sense and will prevent problems.

Many thanks. Paul Faculjak
paul@DataIntegritySolutions.com

 

[JimHorton]

Disi,
You are correct, the files must be registered, but in many cases the more common ones already are, and if not, you can do regsvr32 in code using api's, DLLRegisterServer (not sure of the exact name) and DLLUnregisterServer--which you should run first if you are re-registering, so that the previous path is removed from the registry, and all apps on the machine point to your new path\dll. Also, make sure you put the ocx or dll on the local machine, registering to a network-located file isn't recommended, especially for common ones, like Cmdlg32, for example.
--Jim

 

[DISI]

I cannot find in Access Help something closely related to DLLRegisterServer. I found regeristering a database and "Convert Code That Calls a DLL".

How do I determine common dll's and those that may be the culprets with my application? When I had Access list all the references it comes up with:
VBE6.DLL
msacc9.olb
DAO360.DLL
ICMFILTER.DLL
STDOLE2.TLB
VBE6EXT.OLB

I know my app crashes when it tries to change a database property. I think it also crashes when it tries to create a simple txt file. Can you tell from the references listed above which are responsible for these two actions?

Lastly, I know that regsvr32 is used with DLL's. What about the olb and TLB files my app references?

Thanks Again
Paul Faculjak
paul@DataIntegritySolutions.com

 

[JimHorton]

Paul,
Those are api's, they won't be in Help. I'll see if I can find a declaration (I'm at a different computer now and don't have my apps that use it here) and post it--you'd just copy the declaration to that section of a module.

For debugging which one is the culprit for the crashes, you could remove one by one and try the offending action each time.
--Jim

 

[DISI]

I'd debug if it was crashing on my system. Unfortunately, my user is off site. I've got everything loaded on my machines so I'll wait for the api's and go down that path.

Thanks Paul Faculjak
paul@DataIntegritySolutions.com

 

[nickjar2]

Hi,

I have used the shell command before to register dll's.

Nick

 

[ErikZ]

Nickjar2: There's a shell command for registering DLLs? What is it? How do you do it?

 

[nickjar2]

Erik,

If I remember rightly, i just wrote:

shell "regsvr32 c:\winnt\system32\something.dll"

I THINK that is how I did it. I haven't got Acc in frony of me at the moment sorry.

Nick

 

[JimHorton]

OK, I found the declare. It's not technically an api, it's a function contained in the dll itself. Here's how to declare it:
Declare Function WhateverIWantToCallIt Lib "MSHTMLWB.DLL" Alias "DllUnRegisterServer" () As Long
So, you give the function any name, then after lib, put whatever dll or ocx filename (I think you can put path as well), then alias to dllunregisterserver and dllregisterserver. Apparently the compile inserts this into the finsished product when you create an ocx or dll. Anyway, this worked well for me in a couple of apps where I had some version conflict or some other mess.
--Jim

 

[DISI]

Jim,

This is great. I don't want to sound sooo stupid, but I've learned VBA from a freind and lots of practice. I'll need a bit more clarification on your suggestion.

Do I need to create a function in a module first? I inserted the following into the immediate window and got a compile error.

Declare Function SetReg Lib "C:\Cholesterol Provider Report\ICMFILTER.DLL" Alias "DllUnRegisterServer" ()As Long

Where does the DllRegisterServer part come in?

Also, if I combine all of the steps. I first "Set ref = References.AddFromFile" to register the dll. Then I unregister it and then register it.

Sorry if I need so much hand holding. Paul Faculjak
paul@DataIntegritySolutions.com

 

[JimHorton]

Paul,
You need to put the 'Declare...' statement in a module in the declarations section, ie, right below the 'Option Compare...' etc. statements.
Then, whatever you name the function, (my example was 'WhateverIWantToCallIt'), this is now a function you can call from another sub or function, ie:

Sub Reg()
dim x as long
x = WhateverIWantToCallIt()
end sub

This will now do whatever was aliased by 'WhateverIWantToCallIt', in my example, it would UN-register MSHTMLWB.DLL. So you'd put several of these delcares in the delcarations section, one for unregister, one for register, and name them each differently. A clearer example would be:

Option Explicit
Declare Function UnRegHtml Lib "MSHTMLWB.DLL" Alias
"DllUnRegisterServer" () As Long
Declare Function RegHtml Lib "MSHTMLWB.DLL" Alias
"DllRegisterServer" () As Long

Sub ReReg_HTML()
dim x as long
x = UnRegHtml()
x = RegHtml()
End sub
The above would unreg then re-reg the MS web dll. This is the same as calling...

RegSvr32 /u C:\Winnt\Sytem32\mshtmlwb.dll
RegSvr32 C:\Winnt\Sytem32\mshtmlwb.dll
...from a Shell or from the Run box in the Start menu.
You'd need to put the delcares in with your own Function names, and the dll or ocx you're dealing with, along with the path, if necessary.
--Jim

 

[DISI]

Jim,

This was very clear. Thank you very much. I'll give it a whirl today and let you know. You've been a God send.

Paul Paul Faculjak
paul@DataIntegritySolutions.com

 

[DISI]

Jim,

Need some further help.

I put the following directly below Option Explicit:
Declare Function UnRegDAO Lib "C:\Program Files\Common Files\Microsoft Shared\DAO\DAO360.DLL" Alias "DllUnRegisterServer" () As Long
Declare Function RegDAO Lib "C:\Program Files\Common Files\Microsoft Shared\DAO\DAO360.DLL" Alias "DllRegisterServer" () As Long

I then created the follow sub:

Sub ReReg_DAO()
Dim x As Long
x = UnRegDAO()
x = RegDAO()
End Sub

When I run ReReg_DAO, I get a run-time error '453'
"Can't find DLL entry point DLLUnregisterServer in C:\Program Files\Common Files\Microsoft Shared\DAO\DAO360.DLL

What am I doing wrong?

Paul Paul Faculjak
paul@DataIntegritySolutions.com

 

[JimHorton]

My apologies--most dll's are in C, and that's programming for you--it's CaSe SeNSitiVE, make the 'R' lower case as in DllUnregesterServer
--Jim

 

[DISI]

Bravo. Jim. You've been quite helpful. Thank you so very much.

Paul Paul Faculjak
paul@DataIntegritySolutions.com