I have a Fortran DLL (made using one of the latest Intel oneAPI IFORT compilers) and linked in Visual Studio 2019. One of the entry points contains an argument list of a mixture of Integer4 (Long in VBA) scalars and Real8 (Double in VBA) arrays. I call the function from Excel VBA using a Declaration like this (simplified to make it easy to follow):
Declare PtrSafe Function GetCatalyst Lib "myDll.dll" Alias "#3" (arg1 As Long, arg2 as Long, arg3 As Double, arg4 As Long, arg5 as Long, arg6 As Double) As LongPtr
Where arg1, arg2, arg4, arg5 are just scalar Long values, and arg3 and arg6 are Double arrays with length defined by one of the Long arguments e.g. arg3 is Double(1 to arg2). There are more like 20 arguments, but they follow this pattern.
The Excel call looks something like:
Dim arg1 as Long, arg2 as Long, arg3() as Double
Dim arg4 as Long, arg5 as Long, arg6() as Double
ReDim arg3(1 to arg2)
ReDim arg6(1 to arg5)
'< Some code to make sure the DLL is loaded using LoadLibrary happens here>
' Actual call here
Dim result as Long
result = GetCatalyst(arg1, arg2, arg3(1), arg4, arg5, arg6(1))
This all works fine, all the arguments are properly dimensioned in VBA to match the underlying function in Fortran, BUT then we tried adding another trio of arguments in the middle of the block of arguments, following the same pattern (another Long, Long and Double array). After this, the last three arguments in the list received junk values in the Fortran call, despite VBA apparently passing the correctly initialised values in.
Obviously we checked (and double, even triple checked) the new arguments are properly included in the Fortran (and this had built correctly with the expected compiler-generated interface definition) and that the VBA Declaration AND function call had both correctly been adapted to accommodate the new arguments. We even made a test Fortran application to load and call the DLL and this worked fine.
Finally, we tried loading the DLL function from the function NAME instead of the Ordinal number (“GETCATALYST” instead of “#3”) and this worked. We also tried compiling with a new (previously unused) ordinal number #17 and this also worked. Finally, we tried renaming the compiled DLL and loading this with the same original ordinal of #3, which also worked.
Does anyone know how VBA loads ordinal aliases for external DLL calls? It seems that it somehow caches the ordinal alias and shape/size of the arguments for that function somewhere, and only clears it when you supply a new file name for the DLL? We cannot work out what is going wrong, but it seems to be an Excel VBA issue, and seems to be specifically around using ordinal aliases for Fortran DLL calls.
Excel version is o365 build 2407.
Update: based on feedback (thanks!) I should clarify that the erroneous behaviour (junk arguments being passed from VBA into Fortran) persists even after a full machine restart, so it does not look like a per-session cache of the DLL entry point, but something more persistent.
9