DLL distribution using IVF to be called by Excel/VB

[wma]

Hello,

I have built a software package consisting of an excel 97 spreadsheet containing VB code which calls DLLs built using IVF, to be distributed to a client.

The program runs fine (release version of DLLs) using the machine with which I compiled the DLLs (with IVF installed), but when I run it on other machines it will not work, with the following errors:

On machine with Excel 2003:
"Run-time error '53': File not found: C:sesfloodSESpredDLL.dll"
On machine with Excel 97:
VB code runs but steps over calls to my DLL subroutines without any change to my output arguments.

I have read several posts on this topic, and tried all the solutions posted there, but I still cannot succeed.

My project DLLs link to the following DLLs according to Dependancy Walker:
LIBIFCOREMD.DLL
LIBIFPORTMD.DLL
MSVCR71.DLL
KERNEL32.DLL

I have distributed these DLLs on the target machines, and updated the PATH environment variable. When I run Dependancy Walker on the target machines it has no problems finding the required DLLs (although I do get an error relating to MSJAVA.DLL, which I have seen on other posts). I have also installed the HP executable kit to install support DLLs (such as DFORRT.DLL).

I have also tried statically linking my DLLs, with the same errors. All machines are running Windows XP SP2

Please help me!

PS this is my first post to this forum, but I have found countless life-saving solutions here. Thank you all for your help, particularly Steve and Jugoslav.

[Steven_L_Intel1]

First, you should not redistribute KERNEL32.DLL - that is a system DLL. But I doubt it has any bearing on the situation.

Do this. Write a dummy Fortran program that has a call to one of your DLL entry points and link it against the export library that was created when your DLL was built. The program doesn't have to do anything useful - just contain a call so that it tries to load the DLL. (You can even put a READ (*,*) before it so that the call never gets made.)

Copy the EXE to the target system, NOT in the same folder as the DLLs you copied, and run it. If there is a problem with the DLLs, you should get a more useful error message.

[wma]

Steve,

Thank you for your prompt reply. I did as you suggested, and distributed a fortran executable that called the DLL (I already had one on the build machine that I had used for testing).

I placed the EXE on the target system, in a different folder to the DLLs, and ran it. It ran no problems, returning all results as with the build machine. I tested that the EXE was in fact calling the project DLL by removing the project DLL from the target system, and got expected error (could not find DLL). I put the DLL back and it worked. Running Dependancy Walker on the EXE indicates that it is finding all the distributed DLLs in all the right places.

I'm guessing that suggests there may be something wrong on the Excel/VB side of things. Damn. Is there an extra step within excel with which I need to reference the DLL library?

My VB declaration looks like this:

Option Explicit

Public Declare Sub SESpredDLL Lib "C:sesfloodSESpredDLL.dll" (ByRef WL As Single, ByRef PL As Single, ByRef NthRL As Single, ByRef Wpp As Single, ByRef limb As Long, ByRef numRegStat As Long, ByRef numPredStat As Long, ByRef PredLev As Single, ByRef PredPeak As Single, errID As Long)

The call is like this:

Call SESpred(WL, PL, NthRL, Wpp, mylimb, numRegStat, numPredStat, vbPredLev(1), vbPredPeak(1), errID)

And my FORTRAN declarations are:

subroutine SESpredDLL(WindLev,PenLev,NthRichLev,PPwind,limb,numRegStat,numPredStat,PredLev,PredPeak,errID)

 ! Expose subroutine SESpredDLL to users of this DLL

 !DEC$ ATTRIBUTES DLLEXPORT::SESpredDLL

 !DEC$ ATTRIBUTES ALIAS:'SESpredDLL' :: SESpredDLL

 !DEC$ ATTRIBUTES STDCALL :: SESpredDLL 

 include 'blk1.com'

 real,intent(in) :: WindLev,PenLev,NthRichLev,PPwind

 real,intent(out) :: PredLev(numPredStat),PredPeak(numPredStat)

 integer,intent(in) :: numPredStat

 integer,intent(in) :: limb

 integer,intent(out) :: errID

 !DEC$ ATTRIBUTES REFERENCE :: WindLev,PenLev,NthRichLev,PPwind

 !DEC$ ATTRIBUTES REFERENCE :: PredLev,PredPeak

 !DEC$ ATTRIBUTES REFERENCE :: numPredStat

 !DEC$ ATTRIBUTES REFERENCE :: limb

 !DEC$ ATTRIBUTES REFERENCE :: numRegStat

 !DEC$ ATTRIBUTES REFERENCE :: errID

...

End subroutine SESpredDLL

Sorry, security settings prevented me using the code paste function. And yes, before anyone asks, I have checked the path and file names a million times. I must be going crazy.

Do I have a case matching issue or something? (Bearing in mind that it all works hunky dory on the build machine)

[Steven_L_Intel1]

This isa puzzler. You did build the DLL as a Release configuration, right? (Given what you've said already, you must have, but...)

I am running out of ideas here.

[wma]

Just thought I'd update this thread to say that we eventually resolved this issue. It appears that our anti-virus software (Kaspersky) was interfering with the VBA calls to the DLLs. Only realised because I was using a different anti-virus on the build machine, and when I changed over the VBA calls didn't work anymore.

[Jugoslav_Dujic]

ZOMG. Which just proves my pet peeve thesis that the total amount of damage caused by antivirus software outweighs the one caused by viruses.