ERROR 49 BAD DLL CALLING CONVENTION FROM VBA

[Guaglardi__Paul]

Code behind excel that has been successfully used before to call a DLL yields a new error, Error 49.  Have tried several variations including PTRsafe as well as removing the "alias".  Any ideas out there?

[mecej4]

The list of Fortran runtime error messages at https://software.intel.com/en-us/node/678472 does not have an entry for Error-49. If your DLL was compiled from Fortran sources alone, the indication is that you should consult VBA and Office documentation regarding that error.

[Eugene_E_Intel]

Hello,

I recommend that you look here for various causes of error 49:

https://stackoverflow.com/questions/15758834/runtime-error-49-bad-dll-calling-convention

[Steve_Lionel]

VBA wants to use the STDCALL convention on 32-bit Windows, the Intel Fortran default is the C convention. There are various ways of changing the convention - I would suggest adding:

!DEC$ ATTRIBUTES STDCALL, REFERENCE, ALIAS:"SubName" :: SubName

where SubName is the name of your subroutine or function. In the ALIAS attribute make sure you use the exact case as appears in the VBA call.

[Guaglardi__Paul]

All, thanks for the input.  Yes, there appear to be some differences between the excel of yesterday and the fortran of yesterday.  Steve, we will try your tip and see if this helps us to be able to use the "alias" so as to NOT get the error 49, not the suggested approach, and, at the same time, "link" up the alias so that the VBA can enter the code.  This is where is my head logic-wise and possibly it is not correct.

[Steve_Lionel]

If you show us the declaration of the routine in Excel/VBA and that in Fortran we can help you match them.

[Guaglardi__Paul]

Steve,

The following appeared within the VBA.

HEADER:

Option Base 1

Declare Sub NGCDT Lib "C:\Windows\System\GPS.DLL" Alias "_NGCDT@4" (ByRef MyIOArray As Double)

Declare Function WinTempPath Lib "kernel32" Alias "GetTempPathA" (ByVal nBufferLength As Long, ByVal lpBuffer As String) As Long

BODY:

Public Function NGCDT_OUT(vInputTag_in As Variant, vIOData_in As Variant) As Variant

-----CODE------

-------CODE-------

AND, FINALLY A CALL TO THE SUBROUTINE THAT IS DEFINED IN THE FORTRAN

Call NGCDT(dIOData(1, 1))

NOW.........THE FORTRAN SUBROUTINE ITSELF.

    SUBROUTINE NGCDT ( OUTPUT )

      IMPLICIT NONE

      INCLUDE 'PUBLIC.INC'

      REAL :: HT_41(50),ENTHALPY,Q_FUEL_BTU_HR,METHANECP,SH_FROM_RH
      REAL :: OUTPUT(5000,1) !6-3 ,XC_HPC_Q_M_DOT_RATIO_ACTUAL(20)
      REAL :: SPEEDRATIO_TEMP
      INTEGER I,STG,JMAX,KMAX,J,K,N1,M,IX

      INTEGER XYZ

      INTEGER L,MM,N,O
      
      INTEGER Z, K_MAX, KK !11072017, CASE_COUNT

      CHARACTER*24 DATETIME,DATETIME_BEGIN
      CHARACTER*15 HPC_STATUS,HPT_STATUS,MODEL_STATUS,ENG_DR_STATUS !01102017
      CHARACTER*80 INFILE,OUTFILE,LOGFILE,ALOGFILE
      LOGICAL FILEEXIST,REVERSEFLOW
      CHARACTER *1 STAGEID(10)
      DATA STAGEID/"1","2","3","4","5","6","7","8","9","0"/
      
      NAMELIST /INPUT/ &

ETC....... ETC.....

Your help with this would greatly be appreciated.  We have been fighting for some time now.  Our machines are 64 bit and we can compile 32 bit.  Previously, used Compaq visual fortran, F77.

Thanks in advance.

[Steve_Lionel]

Ok - here's an easy fix. Add to your Fortran routine:

!DEC$ ATTRIBUTES CVF :: NGCDT

[Guaglardi__Paul]

Thank you Steve.  Would it look like this then?

     SUBROUTINE NGCDT ( OUTPUT )

     !DEC$ ATTRIBUTES CVF :: NGCDT

      IMPLICIT NONE

      INCLUDE 'PUBLIC.INC'

      REAL :: HT_41(50),ENTHALPY,Q_FUEL_BTU_HR,METHANECP,SH_FROM_RH
      REAL :: OUTPUT(5000,1) !6-3 ,XC_HPC_Q_M_DOT_RATIO_ACTUAL(20)
      REAL :: SPEEDRATIO_TEMP
      INTEGER I,STG,JMAX,KMAX,J,K,N1,M,IX

      INTEGER XYZ

      INTEGER L,MM,N,O
      
      INTEGER Z, K_MAX, KK !11072017, CASE_COUNT

      CHARACTER*24 DATETIME,DATETIME_BEGIN
      CHARACTER*15 HPC_STATUS,HPT_STATUS,MODEL_STATUS,ENG_DR_STATUS !01102017
      CHARACTER*80 INFILE,OUTFILE,LOGFILE,ALOGFILE
      LOGICAL FILEEXIST,REVERSEFLOW
      CHARACTER *1 STAGEID(10)
      DATA STAGEID/"1","2","3","4","5","6","7","8","9","0"/
      
      NAMELIST /INPUT/ &

ETC....... ETC.....

[Steve_Lionel]

Yes.

[Guaglardi__Paul]

Thank you Steve.  We tried 64 bit and it came back as ERROR 48 FILE NOT FOUND.  We will try 32 bit.

[Guaglardi__Paul]

And debug enabled?  Does debug need to be enabled for this to work?  We appreciate your time.

[Steve_Lionel]

32-bit is what you need for Excel. I recommend no debug, but debug can work in some cases. Intel provides a worked Excel-Fortran example.

[Guaglardi__Paul]

Thank you Steve.  We will get the results of te 32 bit with the most recent line item you have suggested and let you know.  Having the debug off clearly is better as this will enable the ability for the optimization to be enabled and this is needed under the circumstances.  Time.

[Guaglardi__Paul]

Steve, where can I find the Intel worked excel fortran example?

[Guaglardi__Paul]

Steve, first, I/we appreciate any time you devote to this forum especially considering your retired status.  It does appear that there is some confusion as to what DLLs are required, old versus new, etc... .  Is there a comprehensive worked example that functions that can be viewed?  This is in line with the previous question I have posed.

[Steve_Lionel]

I first suggest that you (and anyone else reading here) bookmark the Visual Fortran FAQ. (It is also linked from the top of this forum.) Included there is a link to the page where all the Intel product samples are provided. They used to be installed along with the product, but not since version 17.) You will want the "Intel® Parallel Studio XE for Windows Samples Bundle". Unzip that to a convenient location, and then look in compiler_f > Mixed Language > Excel. That is a simple example of calling a Fortran DLL from Excel.

I am not sure what you are asking relating to your "confusion". By default your DLL will require the Intel Fortran run-time DLLs from the same version you compiled with or newer. The "Release" versions of these are installed on your system and added to PATH so should be found automatically.There is a ReadMe.html in with the example that has more information.

[Guaglardi__Paul]

Steve, prior to getting your reply, thank you by the way, I stumbled upon the following:

https://stackoverflow.com/questions/41353921/writing-a-dll-in-fortran-calling-from-excel from just googling around...sort of speak.

From making some changes in lne with this but appropriate for my code, I was able to move from error 453 to some othr errors which have been deemed internal and are now fixed.

Happy to report that it appears that things could be functionng now as they intended.

Upon checking the code within the bundle, it appears as if the information in that link above is from the bundle of which you speak.

Thanks for the help.  I/we appreciate it.  This was a doosy at times. Spelling doosy questionable.

[Steve_Lionel]

Note that I'm the one who answered that Stack Overflow question! Glad to hear you have things working.

[FortranFan]

Looking at this thread and Quotes #7 and $8, what doesn't make sense is the original post, particularly the comment, "Code behind excel that has been successfully used before to call a DLL yields a new error .."  If the code in Fortran is as shown in Quote #7, it's a mystery how could it have "been successfully used before".

[Steve_Lionel]

It's not a mystery to me - it would have worked as-is with CVF.