Calling Fortran from VB with Type argument

[gib]

I've been happily using a VB Type as an argument to a Fortran subroutine in a DLL.  This Type was made up of a number of Doubles.  I wanted to add a Boolean member (logical in the Fortran derived type), but the program was crashing (on the third call to the subroutine).  I concluded that VB Boolean isn't quite the same as Fortran logical, and changed to using a VB Long and Fortran integer.  To my surprise this also crashed.  In desperation I am now using a Double for the flag, with +1/-1 for true/false.  This works.  It appears that the VB Type is interoperable with a Fortran derived type only if all members are the same type.  I haven't seen this written anywhere - is it true?

[gib]

@Andrew My scepticism was unjustified.  I had to add 3 integers to the Type:

     ...
    recalcable As Boolean
    dummy1 As Integer
    dummy2 As Integer
    dummy3 As Integer
End Type

to make the length up to 144 (apparently VBA integers are 2 bytes), and now the program runs!

Using Double/real(8) to pass a flag makes more sense, I think.  Strange that it's necessary to jump through this hoop.

[gib]

To clarify, in my real program I use +1.0 for true, -1.0 for false, and use > or < 0 to check the flag.

[andrew_4619]

Glad to know things are becoming clearer. It seems your fortran is padded as well, it would be better having some safety by passing the length as an arg which you check at the other side so you know there is a problem if something changes or you get is wrong.

[gib]

Forewarned is forearmed, unless my memory lets me down.  I'll stick with keeping everything Double here.  Nothing surprises me in VBA, but I'm surprised that Fortran is padding to an 8-byte boundary.  It seems that this behaviour has changed since my old compiler came out out - the program works fine for Steve.

[Steve_Lionel]

That it works for me doesn't really tell you much, since the program doesn't test much other than that the assignment didn't die. If actual values were assigned and tested, it would be clearer.

I am confused about the discussion of padding. In the test case you provided, all of the elements but the last are 8-byte double precision. No padding would take place.

[gib]

Steve, it doesn't make any difference if actual values are used.  The program that I provided crashes on my system, and runs on yours.

If the VBA Type is not padded, the program crashes when the last element is Boolean.  I have ascertained that on the Fortran side, when the last element is logical(2) the derived type has a length of 144 bytes (determined with sizeof), as if all the elements were 8 bytes.  On the VBA side, the length of the Type when the last element is Boolean is 140 bytes (determined with lenb).  If I pad the VBA Type with 3 integers, the length becomes 144, and with no change to the Fortran the program executes.

To satisfy requests, here is the code to return values in C and mparr.

[andrew_4619]

GIb what value of /align compiler option is being used? This will make a difference to crash or not crash I think.

[gib]

@Andrew The only /align option that allows linking is /noalign.  Otherwise, with /align:2, /align:4, /align/8 I get the linker message:

Error    2     fatal error LNK1164: section 0x1 alignment (16) greater than /ALIGN value    metab-dll.obj    
Note that in my old compiler /align is a linker option, and it requires a number.

In any case I don't think this is relevant.  The issue was the different lengths of the types in VBA and Fortran, and padding the VBA Type fixed the problem.

[gib]

P.S. /noalign and removing the VBA padding causes a crash.