View previous topic :: View next topic |
Author |
Message |
Thomas
Joined: 18 Feb 2005 Posts: 56 Location: Gummersbach, Germany
|
Posted: Tue Dec 15, 2009 12:48 pm Post subject: 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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Tue Dec 15, 2009 1:19 pm Post subject: |
|
|
Can you post some code for a typical Fortran subprogram in your DLL.
Do you use F_STDCALL in the declaration? |
|
Back to top |
|
|
Thomas
Joined: 18 Feb 2005 Posts: 56 Location: Gummersbach, Germany
|
Posted: Wed Dec 16, 2009 7:45 am Post subject: Code example for calling a FTN95 DLL from VBA |
|
|
Just a simple example for demonstration:
Ftn Source code:
F_STDCALL function COBOCA_LOAD (lnr)
Implicit None
Integer :: COBOCA_LOAD, lnr
COBOCA_LOAD = lnr*lnr
end
VBA Source code calling the DLL:
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
With version 5.21 it was performing well. Since 5.40 I've got problems. |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Wed Jan 13, 2010 10:15 am Post subject: |
|
|
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)? |
|
Back to top |
|
|
Thomas
Joined: 18 Feb 2005 Posts: 56 Location: Gummersbach, Germany
|
Posted: Mon Jan 18, 2010 5:30 pm Post subject: |
|
|
Robert,
Thanks for support. However, it's still not solved.
Today I also tried with Visual Basic 6.0 and found ambivalent behaviour:
a) The executable file created with VB 6.0 performs well.
b) Starting the program from the VB user interface leads to the same error as I found with MS Excel:
Run time error '49'
Wrong DLL call convention.
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. |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Tue Jan 19, 2010 9:32 am Post subject: |
|
|
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 |
|
Back to top |
|
|
qt
Joined: 23 Aug 2005 Posts: 46 Location: Berlin, Germany
|
Posted: Fri Feb 05, 2010 10:25 am Post subject: |
|
|
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 INTEGER*4 argument (Number) and returning the same type (because of the compiler setting INTL), it is using an INTEGER*8 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@, 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 |
|
Back to top |
|
|
Thomas
Joined: 18 Feb 2005 Posts: 56 Location: Gummersbach, Germany
|
Posted: Mon Mar 01, 2010 11:40 am Post subject: DLL problem still not solved |
|
|
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. _________________ Thomas |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Mar 01, 2010 1:12 pm Post subject: |
|
|
/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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Mar 01, 2010 1:41 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Thomas
Joined: 18 Feb 2005 Posts: 56 Location: Gummersbach, Germany
|
Posted: Wed Mar 03, 2010 1:23 pm Post subject: Solved! |
|
|
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. _________________ Thomas |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Wed Mar 03, 2010 3:08 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|