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

Help wanted calling DLLs from 64-bit versions of Excel

DavidWhite
Valued Contributor II
899 Views

I am calling a Fortran DLL from Excel VBA, and have ben doing so successfully for years.

Now one of our engineering suppliers is using a 64-bit version of Office (we haven't migrated from Office 2007 yet).

Can someone help me with my interfaces?

I am using calls like

Private Declare Sub ApproxBayerDensity_F Lib "AHEAProps.dll" (TempC As Double, Value As Double, ByVal Units As String)

Call ApproxBayerDensity_F(T, Value, Units)

the Fortran side is like

Subroutine ApproxBayerDensity_F(TempC, Value, Units)

!DEC$ ATTRIBUTES DLLEXPORT, STDCALL, ALIAS:'ApproxBayerDensity_F' :: ApproxBayerDensity_F

!DEC$ ATTRIBUTES REFERENCE :: Units

...

IMPLICIT NONE

Real (KIND=8),INTENT(IN) :: TempC(1)

Real (KIND=8),INTENT(OUT) :: Value(1)

Character (LEN=20),INTENT(INOUT) :: Units

...

For the 64-bit interface, I now need to use

Private Declare PtrSafe Sub ApproxBayerDensity_F Lib "AHEAProps.dll" (TempC As Double, Value As Double, ByVal Units As String)

Where the variables have to be compatible with the 64-bit Excel. 

 

Do I need to change anything on the Fortran side?

 

Thanks,

David

0 Kudos
3 Replies
Steven_L_Intel1
Employee
899 Views
I don't see anything that has to change on the Fortran side.The STDCALL won't have any effect in this case (you've effectively overridden the effects it would have on x64), but that's harmless.
0 Kudos
DavidWhite
Valued Contributor II
899 Views
Thanks. Steve. What about integer values? On the VBA side, these are now defined as LongPtr instead of Long. Do these still map OK to INTEGER? thanks, David
0 Kudos
Steven_L_Intel1
Employee
899 Views
LongPtr would be INTEGER(8) on x64.
0 Kudos
Reply