Calling a FTN95 DLL from VBA (MS Excel)

After installation of FTN95 Version 5.40 and I get an error in VBA code when calling a dll created by new FTN95 Version.

Error-Message from my German Office Application: Laufzeitfehler '49' Falche DLL-Aufrufkonvention

My translation (not authorised): Run time error '49' Wrong DLL call convention

Deinstalltation of new FTN95 version 5.40 and reinstalltion of Version 5.21 helps. After new compile and link the VBA code is performing well.

Can you post some code for a typical Fortran subprogram in your DLL. Do you use F_STDCALL in the declaration?

Just a simple example for demonstration:

[u:d817bd13fc]Ftn Source code:[/u:d817bd13fc] [color=red:d817bd13fc] F_STDCALL function COBOCA_LOAD (lnr) Implicit None Integer :: COBOCA_LOAD, lnr COBOCA_LOAD = lnr*lnr end [/color:d817bd13fc]

[u:d817bd13fc]VBA Source code calling the DLL:[/u:d817bd13fc] [color=red:d817bd13fc] Private Declare Function COBOCA_LOAD Lib 'CoBoCa.dll' (lnr As Long) As Long Private Sub CommandButton1_Click() Dim wert1 As Long, wert2 As Long wert1 = Cells(1, 2) wert2 = COBOCA_LOAD(wert1) Cells(4, 2) = wert2 End Sub [/color:d817bd13fc]

With version 5.21 it was performing well. Since 5.40 I've got problems.

Hi Thomas

I tried your example with VB6 and it worked exactly as expected. It called the Fortran routine and returned the expected value. I tried with Excel 2007 but could not get it to recognise the DLL. It said 'File not found' which is weird as I gave it the exact path (and of course it worked with VB6). I tried FTN95 5.40 and 5.30. Given Excel's odd behaviour, could you be using a different DLL (or salflibc)?

Robert,

Thanks for support. However, it's still not solved.

Today I also tried with Visual Basic 6.0 and found ambivalent behaviour:

1. The executable file created with VB 6.0 performs well.

2. Starting the program from the VB user interface leads to the same error as I found with MS Excel: [color=red:9d18793645]Run time error '49' Wrong DLL call convention.[/color:9d18793645]

I checked the status of salflibc.dll. The same version is installed 2 times: C:\Programme\Silverfrost\FTN95 C:\WINDOWS\system32 Version no. is 11.3.9.22, dated 2009-10-05 20:00.

I'ld like to send some files. How to attach them?

You may also post to my mail-address.

Hi Thomas

I found no problem with VB6. I can quit happily step through the calling sequence with the VB debugger -- or just run a compiled executable. If you need to send files then send them to ftn95@silverfrost.com

Dear Paul, dear Robert:

Mr. Will sent me his files and I have tested them. I noticed that the internal symbol name of his function

F_STDCALL function SQUARE (Number) Implicit None Integer :: SQUARE, Number SQUARE = Number*Number end

was changed from __imp__SQUARE@4 (FTN95 v5.20) to __imp__SQUARE@8 (FTN95 v5.40)

Mr. Will also sent me his compiler FTN95 configuration: /132 /CHECK /COLOUR /DELETE_OBJ_ON_ERROR /INTL /LOGL /NO_BANNER /PAUSE_ON_ERROR /SAVE /ZEROISE

After testing his dll (built using FTN95 v5.40) it appears to me that although the function should be expecting an INTEGER4 argument (Number) and returning the same type (because of the compiler setting INTL), it is using an INTEGER8 argument and returns an INTEGER*4.

Unfortunately, I have only Excel 2000 running on my system. And I couldn't make his DLL work with this version (due to the lack of an INTEGER*8 type in VB - or at least I didn't find it). I suppose since VB is expecting two arguments because of the symbol's name of the function (__imp__SQUARE@8), it reports an invalid DLL calling convention.

Please find below the relevant information to create the DLL. Of course, I can also send you all the files I set up to analyze the problem. Let me know if you want to have them (my email: support@qtsoftware.de).

Please check. Thank you.

Kind regards, Joerg Kuthe www.qtsoftware.de

Here are the commands being used to create the DLL.

ftn95 SQUARE.f90 slink SQUARE_DLL.opt

The file SQUARE_DLL.opt contains this: dll load SQUARE exportall archive SQUARE.lib file SQUARE.dll

Dear Paul, Dear Robert,

Today I installed new FTN95 version 5.50 and found that my problem with calling a dll from VB is still not solved. Therefore I can not continue with 5.50 and have to switch back to version 5.21.

Obviously there is a difference betweeen dll interfaces created by compiler version 5.21 and 5.40 (or later). Also Joerg Kuthe (QT) reported 3 weeks ago that he found differences and he tried to support me. The only measure to make my application working is to install version 5.21 instead of 5.50 (same computer, same office installation). However, that's not acceptable and can not be the future.

Using dll's created with FTN95 is an important feature for my company and I would appreciate to get the problem solved. Currently my company considers to replace existing fortran installations from another vendor by FTN95. The ongoing problems are not helpful in that situation.

/INTL has no effect as integer(3) is integer*4 and is not the problem. You could try changing your other compilation options. try removing /check or substitute with /debug and the problem may go away. I also included /ex to see what was happening

John

John is right.

Compiling with /check will add extra hidden arguments to the call and could easily prevent the linkage.

/debug will probably be OK but try using no debugging options at first.

Paul, John,

Thank's for your support. My oberservations: Removing /CHECK makes my application working. Replacing /Check by /DEBUG has the same effect. However, I'm still wondering about the different behaviour of versions 5.21 and 5.40. From my point of view it's not an improvement, as I still intent to continue with /CHECK for Fortran-Fortran interaction.

First of all, using /check will normally add hidden arguments so that the stdcall decoration @4 could naturally change to @8. This represents the number of bytes that are passed on the call stack. i.e. two 4 byte arguments rather than one.

If the earlier version of FTN95 did not apply this change then it means that there was a bug in the compiler at that time which resulted in the hidden checking argument being omitted.

I have done quite a lot of work over the last 12 months or so in order to tidy up the behaviour for stdcall protocols but it seems to me that there will always be the limitation that /check uses hidden arguments and the stdcall decoration must reflect this.

For most users this means that a FTN95 stdcall dll must have a /check state that matches the calls made to the dll.

The principle behind the design of the compiler is that /check is intended for development and testing and should be switched off for release versions or when the code becomes stable enough to put into a dll.

When interfacing with VB, it will be necessary to switch off /check or add a dummy argument at the point of call. Since there is no way for you to use the extra argument, there is no point in sending it. i.e. you might as well switch /check off locally when compiling the routine.

This begs the question 'are there parts of the checking mechanism that do not require the extra arguments and can be left switched on'. In theory the answer is YES but you will have to test this to see if it works OK...

If you use '/check /inhibit_check 6' on the command line then the extra information for a CHECK mode call should be suppressed. If this does not work in your situation then it will be necessary for me to look at this whole area again.