Communicate with DLL from VBA Excel (97)

that should do it, maybe handy for future reference unregistering a dll > regsvr32 /u mydll.dll

If its a true DLL in which you utilize its features via "Declare" statements, you don't need to register it.  If it is a COM DLL, you do need to register it, but then you use it in a completely separate fashion (i.e., CreateObject(...)).

Post your entire declare statement...and let us know ALL of the locations where the DLL file itself is located.

Azra,

Here is the statement (changed the name)

Declare Sub GET_CALCULATION_FANALONE Lib "mysupplier.dll" (ByRef S1 As Integer, _
        ByRef s2 As Integer, ByRef InData As Double, ByRef key As keytype, _
        ByRef z1 As Integer, ByRef z2 As Integer, ByRef OUT As Double)


Location of DLL (default)

C:\Program Files\Supplier

Placed DLL myself in my own application path and in C:\WinNT\System32

I will try the regsvr32 command later but I don't think this is necessary... could be horribly wrong of course.

keytype is custom data type, of course, before you ask.

The Regsvr32 command is giving me the LoadLibrary("myfile.dll") failed. GetLastError returns 0x0000007e.

Regsvr32 "C:\Winnt\system32\myfile.dll" gives the same error.

Three dependency files were added to directories, but the Dll function call is still giving the same error.

The Regsvr32 command is giving me this error message now:

"xxx.dll was loaded, but the DLLRegisterServer entry point was not found." .....

More info:

As soon as I place one of the three dependency files ( name "Dforrt.dll") in the System32 directory, the function works without giving the '53' Run-Time error. However, the supplier of the dll suggests to place this and both other dll files in the program directory (my program), not in the System32 directory.

have you tried unregister as per above?
then a lookup in the registry if the dll was in there, removed it?
reboot a regserver, another reboot and try to add them to your references?

just a thought

Bruintje

The regsvr32 /u gives the same error message but instead of DLLRegisterServer it speaks of DLLUnregisterServer. Quit logical :-)

However, the key seems to be the presence & location of thes 3 dependency dll files.

The error messages from regsvr32 are due to the fact that this is not a COM dll, and thus, does not export necessary functions for registering/unregistering.   You do not need to register this file.

By default, a Declare statement searches for the specified file in a predetermined order of directories.  I believe the first is the system folder, and then your program's path.  Ensure the dll in question and its dependencies arent in the system folder, and only in your program's path.  Also, try the declaration minus the ".dll" portion specifying the library name, e.g.,

Declare Sub GET_CALCULATION_FANALONE Lib "mysupplier" ...

Azra,

I do agree on the Regsvr32 part.

But, as soon as I move one of the dependencies out of the system folder, the Run-Time error pops up again.

Also, I only can make it work by specifying the full path in the Lib declaration:

Lib "C:\MyPath\...\mysupplier.dll"

This is not a VB program, but Excel VBA. Isn't there any need somewhere to tell the system to look in the folder where the .xls or .xla and the .dll's reside?

Something in the line of ...

Path = "..." although this of course won't worK.

I have the feeling this should be so simple ;-)

Oh yes, one of the dependency files is called "Msvcrt.dll" and resides in the System32 folder (version 6.00.8797.0) while the one distributed with the mysupplier.dll resides in my program folder and is version 6.00.8397.0

This reminds me of an article I once read: DLL Hell ;-)

Could there be a conflict?

In any case, thanks for your help Azra, I do appreciate it ;-) A lot!

I've contacted our supplier who documented the dll as well, to try to find an answer.

I will try your suggestions, in the mean time.

Thanks Azra, your comments were right on.

I'll include the mail I just got from our supplier, and he did confirm the problem was location of the path.

Also thanks to hes & bruintje, of course.

For the moment everything seems running fine.

calacuccia

"From dll distributor"

Judging from your description, you have two separate problems, both related
with file-search paths and file location.

The first one is the one ending with the VB6 RTE 53 dialogue box, which
means that either the mysupplier.dll file or one of its three child DLLs was
not found.
As the problem seems to be solved by moving the three child DLLs into the
System 32 directory, this should mean that the former location (the
directory including the application file) wasn't within the standard search
path for executable files.  As this path includes, by default, the current
working directory, this should imply that, willingly or not, this system
variable had been set to something else than the location of your
executable (and DLL) file.  Clearly, the problem is the location of the
three child DLLs only, because the "Declare" instruction includes the
complete path to the mysupplier.DLL file (but this can become a source of
troubles in the future, when you will distribute your code to be installed
inside a "C:\Program Files\Something else" directory!).
The problem could be related to the use of the VB compiler in debug mode:
when you run Visual Basic in debug mode, the "Current Working Directory"
system variable is set to the location of the VB6.exe executable, and not
to the location of your compiled code.

This could explain also the second error, producing an error code for "File
Not Found" from inside the DLL, meaning that some archive file (probably
the Nic_ini.ini configuration file, which is the first one to be read from
the DLL) was not found where expected.
I'm sending you the latest release of the DLL file and of its
documentation, as I can't remember which version you did receive.  From
version 2.3.0 onwards, there is the option of setting the search path for
archive files to something different from "(Current Working Directory)
\Nicotra_it", which was the only option with earlier versions (see the
chapter on the SET_DLL_PATH function). This can be particularly useful for
exotic system architectures including distributed, LAN based systems.  You
still have to solve by yourself  the problem of finding the four DLL files:
this is a problem located at the main program level, related with the
architecture and location of your program components and with the specific
settings of the operating system used by your application (and debugger!).