From: Richard Maine on
aeroguy <sukhbinder.singh(a)gmail.com> wrote:
[quoting something, from context, possibly IVF docs]

> "
> In a single-language program, calling conventions are nearly always
> correct,....

Exceptions exist, though I suppose that the "nearly always" does allow
exceptions and is accurate enough. The exceptons that come to mind are

1. "Single-language" does not mean "single-compiler". There are plenty
of contexts where there is reason to try to mix comiled code from
different compilers for the same language. For example, a library might
be compiled with a different compiler because it came from a vendor who
uses a different compiler than you do, or if you use multiple compilers,
just because you don't want to maintain corresponding multiple versions
of the library. I've seen both of those cases.

There are differences in calling conventions among compilers for the
same language. Variation in the placement of the "hidden" argument for
string length is one simple Fortran example.

2. Perhaps unfair in a way, but I have seen it happen and result in
questions here... Sometimes people bring the trouble on themselves. I've
seen people take a perfectly fine procedure and call to it, but then add
compiler directives to try to "fix" some unrelated problem (having
misidentified where the problem is) and manage to explicitly tell the
caller and callee to use different conventions.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: user1 on
aeroguy wrote:

[snip]

>
> I am still experimenting and trying to get at the root of this
> problem.
>
> Looking at the code provided, could this be the problem.
>
> Any ideas?


I'm not sure I can help you with IVF, but I think I got it working with
the gfortran / mingw from www.equation.com

Here is the fortran code (fortrandll.f90) -


Subroutine FortranDLL( Array1, upbound )
Implicit None
! ...argument declarations
Integer :: upbound
Integer :: Array1(1:upbound)

! Local variables
Integer :: i

do i=1,upbound
Array1(i)=Array1(i)+10
end do

End Subroutine FortranDLL

It was compiled like this - (notice the -mrtd option)

gfortran -mrtd -fno-underscoring -shared -o fortrandll.dll
-Wl,--export-all,--out-implib,fortrandll.a fortrandll.f90


And here is the VBA code that called it - (notice passing test(0) by
reference !!)

Declare Sub fortrandll Lib "C:\TEMP\fortrandll.dll" (ByRef Array1 As
Long, ByRef upbound As Long)

Sub Button1_Click()


Dim II As Long
Dim test(5) As Long

For i = 0 To 5
test(i) = i * 1
Next i
II = 6

Call fortrandll(test(0), II)

Range("a1").Value = test(0)
Range("a2").Value = test(1)
Range("a3").Value = test(2)
Range("a4").Value = test(3)
Range("a5").Value = test(4)
Range("a6").Value = test(5)


End Sub




From: aeroguy on
On Dec 9, 9:15 pm, user1 <us...(a)example.net> wrote:
> aeroguy wrote:
>
> [snip]
>
>
>
> > I am still experimenting and trying to get at the root of this
> > problem.
>
> > Looking at the code provided, could this be the problem.
>
> > Any ideas?
>
> I'm not sure I can help you with IVF, but I think I got it working with
> the gfortran / mingw fromwww.equation.com
>
> Here is the fortran code (fortrandll.f90) -
>
>         Subroutine FortranDLL( Array1, upbound )
>         Implicit None
>         ! ...argument declarations
>         Integer :: upbound
>         Integer :: Array1(1:upbound)
>
>         ! Local variables
>         Integer :: i
>
>         do i=1,upbound
>         Array1(i)=Array1(i)+10
>         end do
>
>         End Subroutine FortranDLL
>
> It was compiled like this - (notice the -mrtd option)
>
> gfortran -mrtd -fno-underscoring -shared -o fortrandll.dll
> -Wl,--export-all,--out-implib,fortrandll.a fortrandll.f90
>
> And here is the VBA code that called it - (notice passing test(0) by
> reference !!)
>
>         Declare Sub fortrandll Lib "C:\TEMP\fortrandll.dll" (ByRef Array1 As
> Long, ByRef upbound As Long)
>
>         Sub Button1_Click()
>
>         Dim II As Long
>         Dim test(5) As Long
>
>         For i = 0 To 5
>         test(i) = i * 1
>         Next i
>         II = 6
>
>         Call fortrandll(test(0), II)
>
>         Range("a1").Value = test(0)
>         Range("a2").Value = test(1)
>         Range("a3").Value = test(2)
>         Range("a4").Value = test(3)
>         Range("a5").Value = test(4)
>         Range("a6").Value = test(5)
>
>         End Sub

Yes this is working in gfortran. thanks. i will test similar options
in intel fortran and report back.

thanks again.

From: Jugoslav Dujic on
aeroguy wrote:
> On Dec 9, 9:15 pm, user1 <us...(a)example.net> wrote:
>> aeroguy wrote:
>>
>> [snip]
>>
>>
>>
>>> I am still experimenting and trying to get at the root of this
>>> problem.
>>> Looking at the code provided, could this be the problem.
>>> Any ideas?
>> End Sub
>
> Yes this is working in gfortran. thanks. i will test similar options
> in intel fortran and report back.

FYI, Intel fortran uses __cdecl calling convention as default, while
CVF used __stdcall, which is required by VB. If you compile using
/iface:CVF, you should get the whole CVF routine semantics.
(Project/Settings/Fortran/External Procedures/Calling convention)

--
Jugoslav
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
From: aeroguy on
On Dec 10, 1:51 pm, Jugoslav Dujic <jdu...(a)yahoo.com> wrote:
> aeroguy wrote:
> > On Dec 9, 9:15 pm, user1 <us...(a)example.net> wrote:
> >> aeroguy wrote:
>
> >> [snip]
>
> >>> I am still experimenting and trying to get at the root of this
> >>> problem.
> >>> Looking at the code provided, could this be the problem.
> >>> Any ideas?
> >>         End Sub
>
> > Yes this is working in gfortran. thanks. i will test similar options
> > in intel fortran and report back.
>
> FYI, Intel fortran uses __cdecl calling convention as default, while
> CVF used __stdcall, which is required by VB. If you compile using
> /iface:CVF, you should get the whole CVF routine semantics.
> (Project/Settings/Fortran/External Procedures/Calling convention)
>
> --
> Jugoslavwww.xeffort.com
> Please reply to the newsgroup.
> You can find my real e-mail on my home page above.- Hide quoted text -
>
> - Show quoted text -

Thanks for the replies i am working on them. Will report if
successful.

As a part of my research on solving the fortran dll call from excel
problem that i have listed above, i found a good resource that might
be useful for anyone who is exploring the magic world of mixed
language programming.

http://people.sc.fsu.edu/~burkardt/pdf/keinert.pdf

This pdf contains general guidelines and a number of examples for
linking fortran subroutines to main programs written in c or c++.

Hope this helps someone in future :)