tags:

views:

465

answers:

3

I have the following declaration in a Module:

Private Declare Function gzopen Lib "ZLIB.DLL" (ByVal filePath As String, ByVal mode As String) As Long

The following code line in a function fails, with a 'File Not Found: ZLIB.DLL' error:

lGZFileHandle = gzopen(sPath, "rb")

I'm aware that ZLIB doesn't need to be registered. My question is, where does ZLIB.DLL need to live in order for my code to work? I also know that this code is working on another machine. Currently I have ZLIB.DLL in the same folder as the application exe.

UPDATE

To my relief, the code does work when compiled. But does not work whilst running in the IDE (it does on a different machine). I still have ZLIB.DLL in the application folder. This means that the application path must be being checked for loading the DLL.

To get around this I have tried:

Private Declare Function SetDllDirectory Lib "Kernel32" Alias "SetDllDirectoryA" (ByVal path As String) As Long

and then in the function:

SetDllDirectory App.path

This seems to allow the DLL to load, but I then get a 'Bad DLL calling convention' error instead. The plot thickens.

SOLVED

The answer seems to be here: http://www.zlib.net/DLL_FAQ.txt. It's a case of RTFM I suppose. So, bizzarely whilst in the IDE, the STD_CALL convention is in force, but once compiled the C style calling convention suffices. It still doesn't explain why it works on a different machine in the IDE. Ho hum.

Thanks all for pointing me in the right direction.

A: 

Are you sure ZLIB doesn't have to be registered?

I suggest you register it and try again.

EDIT
Try putting the DLL in your System folder. I believe your program will check there for it.

Jay Riggs
Quite sure. If I try Regsvr32 then I get a 'This file cannot be registered' error.
Jonathan Swift
hmmm, have you tried putting the DLL in your system folder?
Jay Riggs
DLLs directly referenced by the DECLARE statement do not need to be registered.
AngryHacker
A: 

ZLib has to be in the standard DLL load search path. See the MSDN LoadLibrary documentation for specifics on the way DLLs are found and the order of the search for them.

Ken White
+3  A: 

VB6 strayed a bit from the search protocol suggested by Ken (this link is the quick reference).

The usual problem is that the .exe path (search location #1 on the list) is not the path of your VB program, but rather the VB6 IDE. So putting the DLL in the location of your VB program is no good -- unless you change the 'Start In' location of your VB6 shortcut to point to that location.

Alternately, you can put the DLL in one of the other locations specified in my link.

Marc Bernier
Another workaround is to always change the working directory before calling the DLL. I forget the VB6 statements, I think it's ChDrive and ChDir
MarkJ