forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Import External DLL published function () into FTN95 .f95

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 129
Location: Chennai, IN

PostPosted: Fri Jan 12, 2018 6:07 pm    Post subject: Import External DLL published function () into FTN95 .f95 Reply with quote

Dear Paul

Greetings
I have a question, perhaps, very fundamental, hence I am asking here for quick help. I have just searched in our FTN95 forum, but not able to spot of this kind of question's discussion.

I want to import the externally available DLL reference into my .f95 code. In this, I want to create (or instantiate) an object referring to the DLL (exported function object) in .f95 code and then use the published function out of the DLL through the instantiate object handle in .f95.

Let me give an example here.

Assume the external DLL is MyComponent.dll and it has a function SquareIt()

Its code looks like this, it a activex DLL developed in VB, called Mycomponent.dll


Code:
Option Explicit

      Public Function SquareIt(lngNumber As Long)
         SquareIt = lngNumber ^ 2
      End Function



So this function is developed in project "MyComponent" and class module name is MyClass. So, the MyClass has this function SquareIt() as above.

Now, let me show the Main program code, which import the reference to MyComponent.dll

Code:

Public Sub ma()

      'begin procedure

      'create a object reference to the component
      Dim obj As MyComponent.MyClass
      Dim lngArgument As Long
      Dim lngResult As Long

      'create an instance of the object
      Set obj = New MyClass
      lngArgument = 2

      'call the objects SquareIt method
      lngResult = obj.SquareIt(lngArgument)

      MsgBox "The Square of " & lngArgument & _
             " is " & lngResult

      'end procedure
   
End Sub



For explanation, I use the VB6 code here as above. If you notice the codelines in the above code, An object "obj" is created from MyComponent.MyClass, then the object instance is created using "Set obj..", which allocates the memory instance as well here. Further, the SquareIt is called as given in the next line


Code:
 lngResult = obj.SquareIt(lngArgument)



The covenience to the programmer is that when i type "obj." then the published functions will be displayed in our IDE editor, which is one important.

How to do this in our FTN95, by importing the external DLL references. Could you please let me know how this is done in V8.10. And also, if there are, our study reference in FTN95.chm, or PDF, pls. let me know.
_________________
Thanks and Regards
Moorthy
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 873

PostPosted: Fri Jan 12, 2018 6:41 pm    Post subject: Reply with quote

You talk in terms of objects, instantiation, etc. I will skirt around that terminology and show how to create a Fortran DLL function and how to use that function.

The source for the DLL:
Code:
function squareit(L)
implicit none
integer L,squareit
squareit=L*L
return
end function

We build the DLL as follows:
Code:
ftn95 squareit.f90
slink /dll squareit.obj /export:SQUAREIT

The source code for the caller of the DLL:
Code:
program getsquare
implicit none
integer x,xsq,squareit
!
x=7
xsq=squareit(x)
print *,'square of ',x,' is = ',xsq
end program

Building the EXE:
Code:
ftn95 gsq.f90
slink gsq.obj squareit.dll

The output from the EXE:
Code:
 square of            7 is =           49
Back to top
View user's profile Send private message
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 129
Location: Chennai, IN

PostPosted: Sat Jan 13, 2018 3:02 am    Post subject: Reply with quote

Thanks a lot mecej4. Let me try this.
_________________
Thanks and Regards
Moorthy
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1772
Location: South Pole, Antarctica

PostPosted: Sat Jan 13, 2018 7:54 pm    Post subject: Reply with quote

By the way, to All, please mark this post of mecej4 as an example of ideal way of explaining things in these groups and even in general. Genial simplicity.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1928
Location: Sydney

PostPosted: Sun Jan 14, 2018 6:43 am    Post subject: Reply with quote

I agree Dan, thanks mecej4 for the example.
I will be taking this and experimenting with what I can use a .dll for.
Can the 64-bit version be provided, although it appears slink64 may have some useful updates in the next version.

I remember when Pr1me provided dynamic link libraries, which were sold as a way of changing the .exe with upgraded .dll files. As I had (and have now) access to the full build based on .obj and .lib static libraries, I don't appear to required the .dll capabilities.

There is also the problem of accessing modules (and possibly common) in a .dll. This may just be a misunderstanding of the restrictions. Is there any authoritative discussion of this in FTN95.chm or elsewhere ?

I also observe a slight performance penalty with using .dll system libraries, although that may be confused by the longer initial startup delay with larger static .exe build files.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 873

PostPosted: Mon Jan 15, 2018 6:03 pm    Post subject: Re: Reply with quote

JohnCampbell wrote:
Can the 64-bit version be provided, although it appears slink64 may have some useful updates in the next version.

Code:
ftn95 squareit.f90 /64
slink64 squareit.obj /file:squareit.dll
ftn95 gsq.f90 /64
slink64 gsq.obj squareit.dll /file:gsq

I get the impression that slink64 does not require and does not understand EXPORT directives, but it does export the function/subroutine name.

Quote:
There is also the problem of accessing modules (and possibly common) in a .dll. This may just be a misunderstanding of the restrictions. Is there any authoritative discussion of this in FTN95.chm or elsewhere ?

Here is where things get complicated. Using shared modules and global data can violate thread safety, and support from the OS is needed to get things to work correctly and safely. It is best to stick to sharing data through argument lists. Even with simple entities such as file unit numbers, if the DLL and the EXE write to the same unit, one of them may complain that the file is not open or the output may not be in logical sequence.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 437
Location: Morrison, CO, USA

PostPosted: Mon Jan 15, 2018 7:02 pm    Post subject: Reply with quote

I was forced to use a DLL for a "C" library that could not be compiled using SCC. It is used a lot when I run one particular program, but the performance penalty does not appear to be too great.

This might be different when/if more DLL-based routines are run (compute intensive), but really, the interface is pretty clean for the DLL interface.
Back to top
View user's profile Send private message Visit poster's website
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 129
Location: Chennai, IN

PostPosted: Tue Jan 16, 2018 6:13 pm    Post subject: Reply with quote

Thanks mecej4 on /64
Quote:
Using shared modules and global data can violate thread safety, and support from the OS is needed to get things to work correctly and safely. It is best to stick to sharing data through argument lists. Even with simple entities such as file unit numbers, if the DLL and the EXE write to the same unit


I agree with you. I am facing the problem, when I try use the same modules which consist of public function, while attempting to make use of the same data between DLL and EXE.Thats where I face this issue of what you said. If I keep the MOD as part of DLL and USE MOD in EXE, but compilation fails for EXE as the MOD code is missing. Is there any better way to handle this to avoid this compilation error?

Alternatively, the solution to this would be to share by addresses passing, and use the same address location for read/write transactions.But, I agree that this option should handled with extra care as part of program logical flows.
_________________
Thanks and Regards
Moorthy
Back to top
View user's profile Send private message
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 129
Location: Chennai, IN

PostPosted: Wed Jan 17, 2018 9:47 am    Post subject: Reply with quote

Here is one more bit info, forgot to mention earlier.

Quote:
I am facing the problem, when I try use the same modules which consist of public function, while attempting to make use of the same data between DLL and EXE.Thats where I face this issue of what you said. If I keep the MOD as part of DLL and USE MOD in EXE, but compilation fails for EXE as the MOD code is missing. Is there any better way to handle this to avoid this compilation error?


This error happens, even after the /MOD_PATH <MOD file> is defined for the EXE project compilation and building EXE file..
_________________
Thanks and Regards
Moorthy
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group