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

Fortran DLL issue with VBA

kirbychapman
Beginner
588 Views
I have written several DLL's to work within Excel VBA. I typically use a function within Excel to access the function within the DLL.

I just came across an issue that i have never seen before. The FORTRAN code is:
real(8) function CP(T)
!dec$ attributes dllexport :: CP
implicit none

Theta = (T)/100.0d0
CP= 39.060d0 -512.790d0 * (Theta)**(-1)

RETURN
END function

The VBA function is:

Public Function HAIR(Temperature As Double) As Double
HAIR = GP_CP(Temperature)
End Function

Nothing too complicated.

The problem is this -- If the exponent on Theta in FORTRAN code is a positive integer, everything works fine. If it is a negative integer or a real number, the function within Excel returns the #value to the calling cell.

Does anyone have any information on (1) why this would happen and (2) how to get around it? The really odd thing is that this statement only needs to be in the code -- it doesn't even need to be accessed to give the #value response.

My one thought is that somehow the value Theta is "assumed" to be zero, so it crashes. But the value really isn't zero...

Any help is greatly appreciated.
0 Kudos
2 Replies
Les_Neilson
Valued Contributor II
588 Views

I don't know about the original cause of your problem but if the code is really as simple as you show (presumably T and Thetaare declaredreal(8) too) then either :

CP = 39.060d0 -512.790d0 / Theta! for Theta not equal zero

or :

Theta = 100.0d0/T! for T not equal zero
CP = 39.060d0 - 512.790d0*Theta

Les

0 Kudos
Jugoslav_Dujic
Valued Contributor II
588 Views
For the start, you have a mismatch here:

HAIR(Temperature As Double)
real(8) function CP(T)

Absent any declarations not presented and non-default compiler switches, T will be a single-precision REAL in Fortran, not a double precision.

Also, if you're using Intel Fortran, the default calling convention there is C, which is (as far as I know) not supported by VBA. You should compile the Dll with /iface:CVF (External procedures/Calling convention), or use !DEC$ATTRIBUTES to adjust that. (If you're still on CVF, you will be fine in that regard).

0 Kudos
Reply