forums.silverfrost.com

[barrera]

Using:
Windows 8.1 © 2013
64 bit OS, x64-based processor
MS Office 2013 x64

Download the example from https://myengineeringworld.net/2014/03/fortran-dll-excel-vba.html

Copy the “Calling A FORTRAN DLL From Excel & VBA.xlsm” to the folder ..\MySample\Release\x64

Open the .xlsm
Click on the “Enable Content” button

In VBA window, add “PtrSafe” to both Public Declare…
Save and Close



As seen in https://www.silverfrost.com/32/ftn95/ftn95_personal_edition.aspx just downloaded the compiler FTN95 Personal Edition (FTN95PE) version 8.61 from http://www.ftn95.co.uk/ftn95/ftn95-8.61/ftn95_personal.exe

Run "C:\Program Files (x86)\Silverfrost\FTN95\plato.exe"

File > New > Project:
Project Type: Fortran DLL
Name: MySample

OK

In “Project Explorer”, right click on “Source Files”, click on “Add New Item”

Type: Free format Fortran file
Name: MyCode

And paste the content of the downloaded MyCode.f90 in a new .f95 source file

Configuration: Release Platform: x64

Build > Build

So far so good:
“Compiling file: MyCode.f95
C:\Users\BarRErA\Documents\MySample\MyCode.F95(17) : warning 197 - Variable C has been declared but not used
C:\Users\BarRErA\Documents\MySample\MyCode.F95(17) : warning 197 - Variable D has been declared but not used
C:\Users\BarRErA\Documents\MySample\MyCode.F95(51) : warning 197 - Variable I has been declared but not used
Compilation completed with no errors.
Linking...
Creating dynamic link library C:\Users\BarRErA\Documents\MySample\Release\x64\MySample.dl”

When opening the .xlsm, Excel crashes or a exception is thrown.

“FATAL ERROR > Silverfrost exception handler has failed”

Commenting the FRICTIONFACTOR on the .f95 code, compiling again, then going to Excel > tab Sub > clicking RUN (i.e. running the VBA Sub CallDoubleArray()), it works. The problem is with the function call.

I have no clue about what to do. It is my first contact with FORTRAN, I’m an engineer that wants to translate some thermodynamic calculations from VBA to Fortran.

[barrera]

opening via Plato (32 bit) and compiling it again, I got this log:

"Silverfrost 64-bit exception report on C:\Program Files\Microsoft Office 15\Root\Office15\EXCEL.EXE Wed Apr 29 15:08:57 2020


Unknown exception (c004f012) at address 7ffd8cec908c

Within file KERNELBASE.dll
In RaiseException at address 6C
In RpcRaiseException at address 51
Within file RPCRT4.dll
In RpcRaiseException at address 14
In NdrClientCall3 at address F6A
In NdrClientCall3 at address FE
Within file sppc.dll
In SLUnregisterPlugin at address 993
In SLGetPolicyInformation at address 63
In Ordinal7162 at address 12B8
Within file mso.dll
In Ordinal7162 at address 11B4
In Ordinal7162 at address 14C0


RAX = 000000391254e420 RBX = 00000000c004f012 RCX = 00007ffd8ecec750 RDX = 0000000000000000
RBP = 0000000000000003 RSI = 0000000000000000 RDI = 000000391254eaf0 RSP = 000000391254e670
R8 = 000000391254e420 R9 = 00007ffd66dc1438 R10 = 00007ffd8ecfe844 R11 = 000000391254e420
R12 = 0000000000000000 R13 = 0000000000000001 R14 = 000000391254ef28 R15 = 000000391254f228

7ffd8cec908c) mov_q RCX,[c0+RSP]"

[Moji]

I have also similar problem in calling 64-Bit Fortran dlls in 64-Bit Excel.

I used this simple Fortran code:

[Moji]

I am writing this post, to get some help regarding calling 64-Bit Fortran subroutines/functions in Excel.

In the previous post, I explained the process that I used and the corresponding error.

I think it is a compiler bug, but I am not sure about it. Therefore, if you have any experience in calling 64-Bit DLLs in 64-Bit Excel, I would be happy to hear about it.

[mecej4]

Why do you think that your problem is caused by a compiler bug? Here is evidence to the contrary. The DLL that you built using FTN95 on the Fortran source has a well-defined API. Here is a C program that calls the function in the DLL using that API, and runs with no errors and prints the correct result.

[Moji]

Hi mecej4,

thank you so much for your reply.

As I mentioned in my first post, Excel can also call Fortran functions and the results are correct, but Excel crashes later on, as you try to insert a diagram, or when you save the project file, close it and open the project again.

There is a subtle difference between your C program and my Excel case. You start your program, call the fortran function, present the result and end it afterwards. However in my case, Excel should be able to keep working after calling the Fortran function without crashing. In other words, if I close Excel after getting the results (like your C program), nobody would notice that something is wrong.

"Why do you think that your problem is caused by a compiler bug?"
I also managed to call Fortran functions from a C++ program and later on in a C++ DLL, similar to what you did. But then as I imported the C++ DLL into MATLAB software, MATLAB crashed after a while with a silverfrost access violation error message. Here is the link to that topic.

Since these two 64-Bit cases are compeletly independent and both end up with access violation error, I thought that maybe it is a compiler bug. I should also mention that with 32-Bit Fortran DLLs and 32-Bit Excel, everything works fine.

[Thomas]

The request to call a DLL developed with FTN95 from Excel 64 bit becomes more and more urgent for my company. Some of our customers roll out Office 64 bit and we cannot support this version.

We cannot say it's a problem with FTN95; we can also not state it's an MS Office problem. Instead it seems to be a problem with the interface or interaction between both components.

Description:
The DLL calls from Excel work initially, i.e. we get the correct results of the functions. After some time, however, Excel behaves strange and stops working properly. The Excel response is not constantly the same, sometimes it don't give any response and one has to cancel the process with the Windows task manager. Sometimes an error message appears as described below:

[PaulLaidler]

Thomas

prepare_register_details and details_box are functions within salflibc64.dll. They were called when processing an exception that was raised within the ClearWin+ function _set_mg_return_value.

_set_mg_return_value is the internal name for set_mg_return_value@ which in theory was called from your Fortran code.

If you (or someone else) can provide code for a very simple project that demonstrates the failure then (given time) we might be able to investigate further.

[Thomas]

Dear forum users, dear Silverfrost team,

The demand for support regarding FTN95 integration in MS Excel is really not new. Already in October 2012, i.e. 9 years ago, a sent the following request to the "General" forum:

[PaulLaidler]

Thomas

Thank you for this enquiry.

I have carried out a brief initial investigation based on code supplied by Moji. If the failure reported by Moji is due to a fault in FTN95 then it may relate to the calling convention that is used (the passing of arguments on a stack and the cleaning of this stack after the call).

For Moji calls to FTN95 from Exel work initially but there is a crash after a few calls.

It would be helpfully to know if this behaviour (when calling from Exel) is experienced by others. Also it would help to know if the same problem arises when a stand alone Visual Basic program calls into an FTN95 DLL.

[Moji]

Paul,

As you asked for it, I created a stand alone 64-Bit Visual Basic program. This program calls a function from a FTN95 DLL and returns the result.

The program works fine and without any errors.

[PaulLaidler]

Moji

Please display the code for VB, for the Fortran and the SLINK64 script for the DLL.

The fact that it works for VB suggests that FTN95 is functioning correctly.

[Moji]

Here is the Fortran Code (test_code1.f90):

[JohnCampbell]

I am also interested in being able to transfer information between a 64-bit Fortran program and a .xlsx (multi-tab) file.

If a template of basic functionality can be demonstrated with FTN95 /64, that would be a useful achievment, worthy of a section in ftn95.chm !

[PaulLaidler]

John

For the moment you can use the information in the help files for 32 bit FTN95 with Visual Basic. This information is also in the Forum Knowledge Base.

Except one doesn't use F_STDCALL for 64 bits and a call to LoadLibrary is probably not needed.