- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We write a piece of software that is structured as a Delphi executable that calls a Fortran dll. We're working on a new error handling method in which we would like to execute a STOP command within the Fortran, many layers deep inside a subroutine. Early testing suggests that this works well - both the dll and the exe shut down and don't appear to leave any processes behind. However, we have had problems in the past with the STOP command leaving the exe hanging. Can anyone offer any advice on what exactly the STOP command inside the dll does with regards to the calling exectuable and with regards to open files? Are there any issues with Windows 98 as opposed to 2000 or XP that we should be aware of?
Thanks in advance,
David Bradley
Thanks in advance,
David Bradley
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
STOP causes the EXE to exit. I'm not aware of any issues using it from a DLL, nor of any OS-dependent issues.
Steve
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But if the statment is STOP 5 or STOP 'zz' then lots of errors before quitting with the calling vb or Excel also failing.
I also have the problem of a large Fortran code called from VB with hundreds of stop statements several call layers deep with no way to return to the top level and then to the VB.
So what to do. Well by chance with Lahey 90 I discovered that executing an integer division by 0 does it. It jumps from the div by 0 straight to the vb statement after the call with the vb error code set to 11 which is division by 0.
Now my reason for searching here is to find if there is any other way in Visual Fortran. From the dialog here I guess not.
But I have already confirmed that div by 0 does it in Visual Fortran from both vb and Excel VBA.
My test vf code is
subroutine sub1(iopt,ipath)
ipath=3
if (iopt.le.-1) then
iopt=iopt-1
elseif (iopt.eq.0) then
!integer div by 0
iopt=3/iopt
elseif (iopt.eq.1) then
stop 7
elseif (iopt.eq.2) then
stop 'test'
elseif (iopt.eq.3) then
stop
elseif (iopt.eq.4) then
call exit
elseif (iopt.eq.5) then
!float div by 0
a=3.4/(0.)
iopt = a
elseif (iopt.eq.6) then
!non existant file
open(ipath,file='zzzzz',action='read')
iopt=105
elseif (iopt.eq.7) then
print *,'hello'
endif
ipath=4
end
SUBROUTINE FortranCall (iopt,ipath)
ipath=1
call sub1(iopt,ipath)
ipath=5
END SUBROUTINE
my test vb and VBA code is
Option Explicit
Declare Sub FortranCall Lib "Fcall.dll" (num As Long, i As Long)
Sub main()
Static num As Long
Dim ipath As Long
On Error Resume Next
Dim S$
Do
S$ = InputBox("Option")
If S$ = "" Then End
num = Val(S$)
Err = 0
Call FortranCall(num, ipath)
If Err > 0 Then
S$ = "Error" & Str$(Err) & " from FortranCall which is " & Error(Err)
Else
S$ = ""
End If
MsgBox S$ & " Result =" & Str$(num) & ". Got to point " & Str$(ipath)
Loop
End Sub
With option 0, the return is with ipath=3 showing that the rest of sub1 and FortranCall are not executed.
So what do you think?
I also have the problem of a large Fortran code called from VB with hundreds of stop statements several call layers deep with no way to return to the top level and then to the VB.
So what to do. Well by chance with Lahey 90 I discovered that executing an integer division by 0 does it. It jumps from the div by 0 straight to the vb statement after the call with the vb error code set to 11 which is division by 0.
Now my reason for searching here is to find if there is any other way in Visual Fortran. From the dialog here I guess not.
But I have already confirmed that div by 0 does it in Visual Fortran from both vb and Excel VBA.
My test vf code is
subroutine sub1(iopt,ipath)
ipath=3
if (iopt.le.-1) then
iopt=iopt-1
elseif (iopt.eq.0) then
!integer div by 0
iopt=3/iopt
elseif (iopt.eq.1) then
stop 7
elseif (iopt.eq.2) then
stop 'test'
elseif (iopt.eq.3) then
stop
elseif (iopt.eq.4) then
call exit
elseif (iopt.eq.5) then
!float div by 0
a=3.4/(0.)
iopt = a
elseif (iopt.eq.6) then
!non existant file
open(ipath,file='zzzzz',action='read')
iopt=105
elseif (iopt.eq.7) then
print *,'hello'
endif
ipath=4
end
SUBROUTINE FortranCall (iopt,ipath)
ipath=1
call sub1(iopt,ipath)
ipath=5
END SUBROUTINE
my test vb and VBA code is
Option Explicit
Declare Sub FortranCall Lib "Fcall.dll" (num As Long, i As Long)
Sub main()
Static num As Long
Dim ipath As Long
On Error Resume Next
Dim S$
Do
S$ = InputBox("Option")
If S$ = "" Then End
num = Val(S$)
Err = 0
Call FortranCall(num, ipath)
If Err > 0 Then
S$ = "Error" & Str$(Err) & " from FortranCall which is " & Error(Err)
Else
S$ = ""
End If
MsgBox S$ & " Result =" & Str$(num) & ". Got to point " & Str$(ipath)
Loop
End Sub
With option 0, the return is with ipath=3 showing that the rest of sub1 and FortranCall are not executed.
So what do you think?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Full Windows apps don't need consoles, the PAUSE statement, or the STOP statement.
Try putting a PAUSE/STOP in a CVF DLL which hasn't allocated a console. On WinNT 4 the OS will repeatedly try to supply a console and eventually crashes. In Win2K it does likewise with PAUSE but won't crash if you persevere in getting Task Manager to eventually kill the process. STOP on Win2K kills the process. Not the kind of behavior one expects from a Windows app. PAUSE is depreciated in f95. Even in legacy code I avoid STOP in CVF DLL's by using the API to raise an exception a la
!ADDITION
write(6,*) 'Aborted with: iX = ', iX
call RaiseException(EXCEPTION_NONCONTINUABLE_EXCEPTION, 0, 0, 0)
!ADDITION
STOP !Never reached
and return control to the VC++, VB, or Delphi client.
HTH,
Gerry T.
Try putting a PAUSE/STOP in a CVF DLL which hasn't allocated a console. On WinNT 4 the OS will repeatedly try to supply a console and eventually crashes. In Win2K it does likewise with PAUSE but won't crash if you persevere in getting Task Manager to eventually kill the process. STOP on Win2K kills the process. Not the kind of behavior one expects from a Windows app. PAUSE is depreciated in f95. Even in legacy code I avoid STOP in CVF DLL's by using the API to raise an exception a la
!ADDITION
write(6,*) 'Aborted with: iX = ', iX
call RaiseException(EXCEPTION_NONCONTINUABLE_EXCEPTION, 0, 0, 0)
!ADDITION
STOP !Never reached
and return control to the VC++, VB, or Delphi client.
HTH,
Gerry T.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My experience has shown me that STOP will raise an exception to the calling .EXE. ie, if you run a vb app, it will crash. there is no way to avoid it. if you are getting it to hang, I am not sure how that can happen unless you have some sort of error handling that is keeping it from crashing.
what i do in my .dll's is write a series of "RETURN". so if a "bad condition" occurs, then i do a return (set a global flag), and i continue to return until it exits. there is no other way to quit the dll immediately and return to the calling .exe without causing a crash or immediate exit of the app.
hope this helps a bit.
what i do in my .dll's is write a series of "RETURN". so if a "bad condition" occurs, then i do a return (set a global flag), and i continue to return until it exits. there is no other way to quit the dll immediately and return to the calling .exe without causing a crash or immediate exit of the app.
hope this helps a bit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I guess I did not make myself clear.
Use of divide by zero eg
i=0
j=4/i
does exactly what trnsys wants.
Even if the fortran is in a subroutine 20 calls below the call from vb, return to vb occurs immediately with the vb error code set to 11 and no other errors. The vb can then call the dll again.
Use of STOP as suggested by Nashua does not do this as the vb calling task also quits.
Use of divide by zero eg
i=0
j=4/i
does exactly what trnsys wants.
Even if the fortran is in a subroutine 20 calls below the call from vb, return to vb occurs immediately with the vb error code set to 11 and no other errors. The vb can then call the dll again.
Use of STOP as suggested by Nashua does not do this as the vb calling task also quits.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did not suggest using STOP - I simply explained what happened if you used it. STOP is certainly not appropriate here.
Steve
Steve
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page