Calling IVF-made DLL from VB 6.0?

[okubo]

Nice to meet you everyone! I found this forum yesterday,
and this is my first posting here.

I want to build DLL subroutine by Intel Visual Fortran 8.1,
and the DLL is to be called from Visual Basic 6.0.

Then I wrote tiny "rehearsal" program to check my knowledge
enough to design that DLL. The source code quoted below is
what I wrote, to double components of a 3x4 matrix in VB
using fortran DLL subroutine.

Fortran DLL build was successful and the built DLL was
copied to the folder which contains VB project.
Now VB program is carried out, but it fails at the line
'MyDLL (3), (4), mat' with error message:

Execution error '53':
File not found:C:Test_VB_DLLMyDLL.dll

[Note that my Windows is Japanese version,
so the original error message is also in Japanese.
The message wrote above is my free translation!]

Of course, MyDLL.dll is placed exactly that folder.

Would anyone please tell me why my DLL cannot called
from VB project?

Code:

================================ Visual Basic 6.0

Private Declare Sub MyDLL Lib "C:Test_VB_DLLMyDLL.dll" _
(n1 As Long, n2 As Long, mat() As Double)

Private Sub cmdDouble_Click()

  ' Initialize a matrix
  Dim mat(1 To 3, 1 To 4) As Double
  For i1 = 1 To 3
    For i2 = 1 To 4
      mat(i1, i2) = 10# * CDbl(i1) + CDbl(i2)
    Next i2
  Next i1

  ' Doubling by DLL
  MyDLL (3), (4), mat

End Sub


======================== Intel Visual Fortran 8.1

subroutine MyDLL( n1, n2, mat )

  !DEC$ ATTRIBUTES DLLEXPORT :: MyDLL
  !DEC$ ATTRIBUTES ALIAS : 'MyDLL' :: MyDLL

  implicit none
  integer(4) :: n1, n2
  real(8), dimension( 1 : n1, 1 : n2 ) :: mat

  mat = 2.0 * mat

end subroutine

[anthonyrichards]

The simplest answer appears to be that you have not written the correct code to call the subroutine that you have named 'MYDLL'. You should use CALL MYDLL(3,4,MAT), I think.

Anyway, calling FORTRAN dll's from Visual Basic has come up here a lot in the past, especially when dealing with VB calls from EXCEL. You can find lots of help on this subject if you do a search on this board using 'EXCEL FORTRAN' as the search string.

Here is a reply I gave in the past...

Code:

I went through this.
On the principle of learning to walk before you try running,
I coded the simplest code I could think of to add and/or 
multiply the contents of two cells and get the correct answer returned.

I have been able to get correct values returned to an EXCEL
cell using the formula reference =DoMult(b2,c2) for example
{to multiply the contents of the two indicated cells},
so long as I include the REFERENCE attribute in the compiler
directive included in the FORTRAN code for function DOMULT.
If I omit REFERENCE and use STDCALL alone, the number returned
is wrong.
If I include both attributes, as shown below, I get the correct value
returned to EXCEL.

Here is the FORTRAN code used to create the dynamic-link
library DLL2_TEST.DLL, which was copied to the /SYSTEM/ folder, 
which is in most search paths, so that it will be found automatically
	FUNCTION COMPUTEMULT ( ARG1, ARG2 )
!DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE,ALIAS:'ComputeMult' :: COMPUTEMULT
	REAL*4 ARG1, ARG2, COMPUTEMULT

	COMPUTEMULT =  ARG1  *  ARG2 

	END FUNCTION COMPUTEMULT

	FUNCTION COMPUTEADD( ARG1, ARG2 )
!DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE,ALIAS:'ComputeAdd' :: COMPUTEADD
	REAL*4 ARG1, ARG2, COMPUTEADD

	COMPUTEADD =  ARG1  +  ARG2 

	END FUNCTION COMPUTEADD

	SUBROUTINE COMPUTEBOTH ( ARG1, ARG2, ARG3 )
!DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE,ALIAS:'ComputeBoth' :: COMPUTEBOTH
	REAL*4 ARG1, ARG2, ARG3(2)

	ARG3(1) =  ARG1  *  ARG2 
	ARG3(2) =  ARG1  +  ARG2 

	END SUBROUTINE COMPUTEBOTH

Here is the VisualBasic code used in the EXCEL worksheet
(I have spread the longer PUBLIC statements over two lines for ease of
visibility in this restricted space)
essentially, I use 'wrappers' such as DoAdd( arg1, arg2) etc. for the calls to
the FORTRAN functions , such as ComputeAdd(X,Y). The message boxes were just for show.

Public Declare Function ComputeMult Lib "C:Winntsystem32dll2_test.dll"
 (A1 As Single, A2 As Single) As Single
Public Declare Function ComputeAdd Lib "C:Winntsystem32dll2_test.dll"
 (A1 As Single, A2 As Single) As Single
Public Declare Sub ComputeBoth Lib "C:Winntsystem32dll2_test.dll"
 (A1 As Single, A2 As Single, A3 As Single)
Public Function DoMult(X As Single, Y As Single) As Single
MsgBox "X= " & X
MsgBox "Y= " & Y
Z = ComputeMult(X, Y)
MsgBox "X*Y= " & Z
DoMult = Z
End Function

Public Function DoAdd(X As Single, Y As Single) As Single
MsgBox "X= " & X
MsgBox "Y= " & Y
Z = ComputeAdd(X, Y)
MsgBox "X+Y= " & Z
DoAdd = Z
End Function

Public Function DoBoth(X As Single, Y As Single,
 ISWITCH As Integer) As Single
Static Z(1 To 2) As Singl
e
MsgBox "X= " & X
MsgBox "Y= " & Y
MsgBox "Iswitch= " & ISWITCH
Rem Iswitch=0 calls routine to get both
Rem values and returns the first
If ISWITCH = 0 Then
Call ComputeBoth(X, Y, Z(1))
MsgBox "First value = Product = " & Z(1)
DoBoth = Z(1)
Else
Rem Iswitch not =0 calls routine to get both
Rem values and returns the second  
Call ComputeBoth(X, Y, Z(1))
MsgBox "2nd value = Sum =  " & Z(2)
DoBoth = Z(2)
End If
End Function
 
 
 
Reply   
 
 Re: Visual Fortran dll call from Excel/VBA  Options      
 
su1 
Registered User 
Posts: 0
Member Since: 10-30-2001 

 
 Posted: 09-20-2002 06:27 AM ID#: 4726 (Viewed 379 times) 


Thanks!  
 
 
Reply   
 
 Re: Visual Fortran dll call from Excel/VBA  Options      
 
 sblionel 
Moderator 
Posts: 4762
Member Since: 03-12-2002 

 
 Posted: 09-20-2002 07:02 AM ID#: 4727 (Viewed 379 times) 

Tony,

In your example, you can omit both STDCALL and REFERENCE and 

it should work. STDCALL by itself changes the default argument passing to 

VALUE, which is why you needed to add REFERENCE. But the default is to use 

the STDCALL mechanism (not the same as explicitly saying STDCALL) and to pass by reference.

Steve 
 
 
 

Message Edited by anthonyrichards on 03-18-2005 02:04 AM

[okubo]

Thank you very much, Anthony!

My DLLs does not work yet, but Your DLLs does work successfully

so thatit has been proved myPC environment has no problem.

And thanks again for search-target keywords.

Theywill be helpful for me as a DLL beginner.