VB.NET to Fortran Arrays

VB.NET to Fortran Arrays

I neet to retrieve calculation results in an array, created by the Fortran code: SUBROUTINE GetResults(ANSWERS) !DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE,ALIAS:"GetResults" :: GetResults !DEC$ ATTRIBUTES REFERENCE :: ANSWERS include "GENERAL.INC" REAL ,intent(out)::ANSWERS(10,9,3,10) DO 100 I=1,10 DO 100 J=1,9 DO 100 K=1,3 DO 100 L=1,10 ANSWERS=VBAS(I,J,K,L) 100 CONTINUE RETURN END From vb.net: Private Declare Sub GetResults Lib "SERI.dll" Alias "Results" (ByRef Answers As Single) Dim NewAnswers(0 To 9, 0 To 8, 0 To 2, 0 To 9) As Single GetResults(NewAnswers(0, 0, 0, 0)) For K4 As Integer = 1 To 4 For K1 As Integer = 1 To 3 For K2 As Integer = 1 To 9 For K3 As Integer = 1 To 10 V = NewAnswers(K4 - 1, K2 - 1, K1 - 1, K3 - 1) If V <> 0 Then Debug.Print("New: " & K4.ToString & " " & K2.ToString & " " & K1.ToString & " " & K3.ToString & " " & V.ToString) End If Next Next Next Next This gets results 1 cell at a time, but works: SUBROUTINE Results(LAY,I,J,K,V) !DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE,ALIAS:"Results" :: Results !DEC$ ATTRIBUTES REFERENCE :: LAY !DEC$ ATTRIBUTES REFERENCE :: I !DEC$ ATTRIBUTES REFERENCE :: J !DEC$ ATTRIBUTES REFERENCE :: K !DEC$ ATTRIBUTES REFERENCE :: V include "GENERAL.INC" INTEGER ,intent(in)::LAY INTEGER ,intent(in)::I INTEGER ,intent(in)::J INTEGER ,intent(in)::K REAL ,intent(out)::V V=VBAS(LAY,I,J,K) RETURN END Private Declare Sub Results Lib "SERI.dll" Alias "Results" (ByRef LAY As Integer, ByRef I As Integer, ByRef J As Integer, ByRef K As Integer, ByRef V As Single) Dim V As Single Dim Answers(10, 9, 3, 10) As Single For K4 As Integer = 1 To 4 For K1 As Integer = 1 To 3 For K2 As Integer = 1 To 9 For K3 As Integer = 1 To 10 Results(K4, K2, K1, K3, V) Answers(K4 - 1, K2 - 1, K1 - 1, K3 - 1) = V Debug.Print(K4.ToString & " " & K2.ToString & " " & K1.ToString & " " & K3.ToString & " " & V.ToString) Next Next Next Next

publicaciones de 9 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Your code got formatted poorly when you pasted it, so I can't read it. I will point you at the two VB-calling-Fortran samples provided with the product under "MixedLanguage" - each uses arrays, one is simple, the other uses SafeArrays.

Steve - Intel Developer Support

Steve,

If A(0:3) and B(1:4) are arrays, will B=A pair up B(1) with A(0)? This seems to be the case. Have I got that right?

In the Mixed Language sample VB-Calls-Fortran, when I step through the code with F11, visual studio 2012 only steps through the vb code and not the fortran code. How can I get it to step through the fortran code?
Thanks,
Brian in Austin, TX

That's correct,      B=A will result in    B(1)=A(0)  etc.  B and A need to match in size and shape, but the bounds don't need to match.

You could also write explicitly B(1:4) = A(0:3),   even if these were sections of larger arrays.

The README contains instructions for debugging Fortran code, but I suspect the fine detail may refer to an older version of Visual Studio.

You should right-click on your VB project and select "Properties". Select "Debug", scroll to the bottom of the page, and check the box "Enable native code debugging".

Yes! I changed the option, and debugging now works :)

I have a similar problem with another project that makes a dll out of fortran, and I call a routine in the dll from Excel VBA.  I have set Start External Program to the path of Excel.exe and I entered the path for the excel workbook in Command Line Arguments.  When I press F5, Excel starts and loads the workbook.  I then run a VBA macro in the workbook which calls the dll. Everything runs correctly but the code does not stop at breakpoints in the fortran in visual studio.  Is there something else that needs to be done to get debugging to work?

Assuming that you are doing a debug build, make sure that the DLL being loaded is actually your debug DLL.  Sometimes a release or older version of the DLL can be picked up first due to the order that paths are searched for DLLs.

You can check this at runtime by:

- starting Excel under debug (Debug > Start debugging)

- set a breakpoint with the VBA editor of Excel inside your VBA code that references the DLL (i.e. an Excel breakpoint, not a Visual Studio breakpoint).

- execute your VBA code such that it hits the VBA breakpoint (this step is to get Excel to load your DLL)

- Back within VS, Debug > Break all (excel will stop being responsive)

- Use Debug > Windows > Modules to list the 14.2 billion DLL's that are loaded by the Excel process.  Find yours.  Check its path, timestep, symbol status, etc.

 

 

Brian,

What you describe definitely works, with the proviso that the correct DLL has been loaded, as described by Ian.

What I normally do (since my app must be installed in a folder other than the Debug folder), is copy the Debug version of the DLL to the normal runtime location of the app.  The catch is remembering to do so after every build.

In regard to your comments about setting the runtime arguments for Excel.  I have found that this is not necessary.  the External Program setting starts up Excel, and you can then load the required workbook from there.  The debugger stops inside your DLL at the first breakpoint encountered.

Regards,

David

Quote:

David White wrote:

What I normally do (since my app must be installed in a folder other than the Debug folder), is copy the Debug version of the DLL to the normal runtime location of the app.  The catch is remembering to do so after every build.

If you are not referencing things relative to the location of the DLL itself, an alternative is for the VBA code in the workbook_open event to first try and load the DLL from the Debug directory of the Visual Studio project heirarchy.  If the DLL cannot be found there, then carry on with a normal load.

If your DLL is normally loaded as a consequence of a path search, then you can also modify the path prior to invoking Excel and put the Debug directory ahead of the normal installation directory of the DLL.

(I've recollection of trying to modify the search path for DLL's from within Excel itself too - in order that the Fortran runtime DLL's can be picked up from a particular location.  I can't remember how that went.)

Thanks for replies.  I have to appologize because I got my projects mixed up.  When I said the dll was made from fortran code, I should have said vb.net code.  So this forum was not the place for this question.  Sorry about that.

I did try the suggestions, though.  I put a unique Msgbox call into the code, and rebuilt, so I'd know the right one was running.  I sent my project to a friend with VS2010, and he says debugging works just fine for him.  I've got VS2012. We compared his Tools/Options with mine and didn't find anything there.  I think I will uninstall and reinstall my VS, or maybe try to find a copy of VS2010.

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya