Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

EXCEL DLL CALLING ARGUMENT PROBLEM

jlgilber
Beginner
479 Views
I have two dll's. Both originally written with CVF 6.6 and converted to Intel Visual FORTRAN 11.1.
One of these works fine. I recompiled the second one recently and put it in use and it gets an error with passing the calling arguments. I compile it with CVG 6.6 and it works fine. I compile it with IVF and it will not work. I tried eliminating all but one calling argument and I cannot get it to work. I tried a string as the variable, I tried an Integer (both sizes), and I tried a REAL variable, and it would not work. If I remove all variables in the call it works fine.

I took the project that works and copied that entire folder to a new folder, then deleted all of the FORTRAN routines, then added the second projects FORTRAN routines (attempting to use a "good working" project file), then added the programs to the project and rebuild my DLL. It did not work.

***** Here is the DECLARE STATEMENT in my EXCEL module ******
Private Declare Sub DRAWMDLL Lib "H:\\Microsoft Visual Studio\\MyProjects\\Copy of Dealem2000\\Release_Intel_DLL\\DrawmDLL.DLL" (BigArray As Double, ByVal LngArraySize As Long, ByVal StrInputPath As String, ByVal LngLength1 As Long, ByVal StrOutputPath As String, ByVal LngLength2 As Long, ByVal StrParametersFileIn As String, ByVal LngLength2 As Long, ByVal StrForecastFileIn As String, ByVal LngLength2 As Long, ByVal StrMonRandomFileIn As String, ByVal LngLength3 As Long, ByVal StrDayRandomFileIn As String, ByVal LngLength4 As Long, ByVal StrAnnRandomFileOut As String, ByVal LngLength5 As Long, ByVal StrMonRandomFileOut As String, ByVal LngLength6 As Long, ByVal StrDayRandomFileOut As String, ByVal LngLength7 As Long, ByVal StrRMFileOut As String, ByVal LngLength8 As Long, ByVal StrVersion As String, ByVal LngLength9 As Long)

***** Here is the CALL STATEMENT in my EXCEL module ******
Call DRAWMDLL(BigArray(0), LngArraySize, StrInputPath, LngLength1, StrOutputPath, LngLength2, StrParametersPathIn, LngLength3, StrForecastPathIn, LngLength3, StrMonRandomFileIn, LngLength3, StrDayRandomFileIn, LngLength4, StrAnnRandomFileOut, LngLength5, StrMonRandomFileOut, LngLength6, StrDayRandomFileOut, LngLength7, StrRMFileOut, LngLength8, StrVersion, LngLength9)

I thought that I had compiled this project in IVF (in the past) and that it ran, but cannot verify that, so it is possible that this project has never worked with IVF.

Any suggestions/help is appreciated.
0 Kudos
6 Replies
Wendy_Doerner__Intel
Valued Contributor I
479 Views
Joel,

Here are some resourcesto help

an article on: converting from CVF to IVF and also an example that calls a Fortran DLL from Visual Basic instaled on your system at:

\Samples\C:\Users\wadoerne\Documents\MixedLanguage\VB-Calls-Fortran

I would suggest looking at the article and seeing that some interface checking is different with our compiler. You could try to remove -warn-interfaces to see if that helps.

If not can you give us the error message.

Thanks,

------

Wendy

Attaching or including files in a post



0 Kudos
DavidWhite
Valued Contributor II
479 Views
You may find this thread useful.

Regards,

David
0 Kudos
jlgilber
Beginner
479 Views
I have tried as many options as I can think of with trying to pass even one argumnet with no success. The error message that I get is

Run-time error '49':
Bad DLL calling convention

Are there project settings that affect the calling argumnets other that the "DATA" sizes?
0 Kudos
Arjen_Markus
Honored Contributor I
479 Views
There are two calling conventions: cdecl and stdcall.

stdcall is the old convention used by default by CVF (and it typically results in internal
names like MYROUTINE@8.

cdecl is the current standard (IIUIC) and that is used by default by Intel Fortran. This
leads to internal names like "MYROUTINE" - without the @8 (the number of
bytes expected in the argument list).

The difference is in the way the stack is cleaned up - by the caller or the callee. So if you
get the convention wrong (i.e. the caller expects convention A and your DLL uses convention B),
then the stack is corrupted.

My guess is that that is what is going wrong. You should experiment with the compiler options for IVF
to see if that makes a useful difference. I can not recommend any settings a priori, as I do not
know enough of your system.

Regards,

Arjen

0 Kudos
IanH
Honored Contributor II
479 Views
Yes.

You've shown us the VB declaration and call, which is only half of the story. Show us the Fortran side of things (the subroutine statement, the declarations for all the arguments, any compiler directives in the source code, etc) as well as letting us know the compile options that you are using. Otherwise we are all just guessing.

0 Kudos
jlgilber
Beginner
479 Views
The compiler option "stdcall" was the key. I went to my "working" project and I had a statement for the "stdcall" option in that routine along with the "!dec attributes" as follows:


!dec$ attributes dllexport :: DrawmDLL !This exports the name

!dec$ attributes alias : "DRAWMDLL" :: DrawmDLL !This sets the name

!dec$ attributes stdcall, REFERENCE :: DrawmDLL
!dec$ attributes MIXED_STR_LEN_ARG :: DrawmDLL

Thanks for everyones input.

0 Kudos
Reply