Welcome to our forums
Hi group,
Does anyone have a working example of the following routines please:
START_PROCESS@, CISSUE@
Thank you for any assistance
Mike,
I prefer start_process_and_wait@. Example:
winapp
program test
implicit none
include <windows.ins>
integer*4 j
character*120 ifile
c create example text
ifile = 'example_text.txt'
open(10,file=ifile,err=100,status='unknown')
write(10,'(A)',err=100)'This is my example text.'
100 close(10)
c start notepad with text, start paint
j = start_process_and_wait@('notepad',ifile,0)
j = start_process_and_wait@('mspaint.exe',char(0),1)
end
Information from cwplus.enh file:
A new ClearWin+ function START_PROCESS_AND_WAIT@ has been added as an alternative to START_PROCESS@. The new function allows other processes to refresh the screen etc.
INTEGER FUNCTION START_PROCESS_AND_WAIT@(COMMAND, PARAMS, WAIT_TIME) CHARACTER*(*) COMMAND,PARAMS INTEGER WAIT_TIMEAll arguments are input INTENT(IN) arguments. If WAIT_TIME = -1 the behaviour is the same as START_PROCESS@. If WAIT_TIME = 0 the behaviour is the same as START_PPROCESS@. Other values give the time in milliseconds before an internal call to YIELD_PROGRAM_CONTROL@(Y_TEMPORARILY). N.B. Unlike START_PROCESS@, this function requires CLEARWIN.INS or its equivalent.
Wilfried
Hi Mike,
I don't iuse CISSUE@ but I do have a facility to launch Notepad or Calculator as per this example:
INTEGER FUNCTION Launch2_FN()
C -------------------------------
C
C Launch Calculator
C
C -----------------------------------------------------------------
INTEGER START_PPROCESS@
IA = START_PPROCESS@('Calc.EXE',' ')
IF (IA .NE. 0) CALL POP('Failed to start Calculator')
Launch2_FN = 1
END
They are INTEGER FUNCTIONs as they are used in the Clearwin+ system to respond to menu commands. It is a bit more elaborate to launch Excel as even the default location changes from version to version, let alone if the user has not installed to the default folder, but one can do things like this:
C Office 2003
C
IA = START_PPROCESS@('C:\\Program Files\\Microsoft Office\'// &
& 'Office11\\Excel.EXE',' ')
C
C Office 2007
C
IF (IA .EQ. -1) THEN
IA = START_PPROCESS@('C:\\Program Files\\Microsoft Office\'// &
& 'Office12\\Excel.EXE',' ')
ENDIF
and so on. (The & in column 73 makes this compile in fixed and free formats). The time taken to try several locations for Excel is small compared to how long it takes to launch it, but you can search for Excel.exe and then worry about which version to use if more than one is found.
It is possible to inhibit the launch of more than one copy of a child program, even a child you wrote yourself using Windows messages.
Eddie
Oh, POP is a routine of mine to display a message in a pop up window, and this is Pprocess@ which launches the program but doesn't wait for it to complete.
E
Thanks for the feed back Gents, I may have sent you down the wrong path however.
I am looking to execute DOS commands, I have constructed the following routine:
As you can see I am trying to use the DOS command TYPE to display the contents of a text file in a command window.
I was not sure if I needed to use the DOS cmd command first?
SUBROUTINE DOS_OUT
winapp
implicit none
include <windows.ins>
integer*4 j
character*120 ifile
PRINT*,'DOS_OUT '
j = start_process_and_wait@('TYPE FSMENU.TXT',char(0),0)
return
end
Why do you want to use the old DOC type command? What do you think about the following?
subroutine disp_text(ifile)
implicit none
integer*4 j
character*120 ifile
j = winio@('%`ca[]%es%sc%ww[no_border]&','EDIT_FILE',ifile)
j = winio@('%`100.35eb[vscrollbar,hscrollbar,fixed_font]','*',0)
end
Define your text file as character*120 ifile, then use call disp_text(ifile).
Wilfried
For Eddie:
I'm not sure if this could be of interest for you, but usually you can find the path to an application within in Windows registry (F95 style):
winapp
program test
implicit none
include 'windows.ins'
character*256 search,AppPath
search = 'winword.exe' ! the programme you are looking for
call FindPath(search,AppPath)
print*,AppPath(1:80)
end
subroutine FindPath(search,AppPath)
include 'win32api.ins'
integer,parameter::HKEY_LOCAL_MACHINE=Z'80000002'
integer*4 j,l,hkey
character*256 search,RegPath,AppPath
RegPath = 'Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\'//search
j = RegOpenKey(HKEY_LOCAL_MACHINE,trim(RegPath),hKey)
l = 256
j = RegQueryValueEx(hKey,'path',CORE4(0),CORE4(0),AppPath,l)
j = RegCloseKey(hKey)
return
end
Wilfried
Hi Wilfried,
The only reason for using the DOS stuff as written in the original source is to build a version of the software which will run in a command window on a Windows 32 system.
This will allow me to establish that all the necessary source is available for porting to either a 32 or 64 bit system.
At that point it is current thought that a GUI based on Clearwin+ will be used and any DOS dependent stuff removed from the system. I should also say that the source was originally developed using Watcom F77.
Hope this helps you understand my dilemma, thanks again for your assistance but I still think I need to be able to issue DOS commands?
Hi Mike,
OK, in this case it might be the simplest way to use
integer*4 j
call cissue@('type my_text.txt',j)
Wilfried
Hi Wilfried,
I haven't used CISSUE@ although I know of it. Does it support piping? e.g.
DIR >DIRECTORY.TXT
Thanks for the Registry info/code. Mike's issue is that his old DOS/Watcom F77 program does the clever stuff by running a standard DOS command and piping the result to a file, which he can interrogate with string processing, which is a clever workaround the limitations of DOS as well as exploiting some of the extensions in Watcom's compiler to get round the limitations of its library. In this context, 'limitations' is relative, because it has EXDOS (EXecute DOS?) and a few constructs that didn't make it to the Fortran standard, e.g. LOOP and QUIT.
I was reminded of the one time I used RATFOR - the preprocessor that allowed one to program in a so-called 'structured' way in Fortran-66 and then translated it for you. My advice to Mike was to get his application working in FTN95 before trying his hand at Clearwin+, as otherwise there are too many targets. CISSUE@ looks to me like a substitute for EXDOS.
Eddie
Does CISSUE@ require:
include <CLEARWIN.INS> ????
When included the compiler creates an error:
C:\Program Files (x86)\Silverfrost\FTN95\include\CLEARWIN.INS(729) : error 904 - Return type is expected. Found (REF,VAL,REF,VAL):INTEGER*4 (In include file C:\Program Files (x86)\Silverfrost\FTN95\include\CLEARWIN.INS
ok i've got it thanks everyone
syntax:
call cissue@('cmd /c type FSMENU.TXT',j)
Hi Eddie,
yes, cissue@ supports piping - if the DOS command supports it: call cissue@('cmd /c type example_text.txt > garbage.txt',j) Of course cissue@ itself has no such functionality.
Wilfried
Thanks everyone seem to have this working now
Have anyone experience such strange behavior of CISSUE@(Command): when something wrong in the code (for example you forgot to open the file and started to read, and safety mechanism silently redirected the code to not cause any problems. So, actually there is no error in the code because it was self-corrected) still the SISSUE@ refuses to do its job to launch some other program. For example, here is specifically what i do
Command = 'h5dump.exe -H DirOfHDF5file/HDF5file1.h5 > Header1'
call cissue@(Command,ierr)
Here CISSUE starts external program H5dump and H5dump opens header (this is why -H is here) of the file HDF5file1.h5 in the directory DirOfHDF5file and saves the output by piping it into file Header1 which i then open and use.
More correctly to say, CISSUE actually indeed starts this external program H5dump, and this is because the ierr is reported as zero, which means there was no error executing the Command. Formally there was also no errors somewhere in the other code, only H5dump complained that it can not do what it was asked for. Visually examining using SDBG debugger i find that there is no any problems with the CISSUE's Command1 text before and after, all seems the same as usual but the error and refusal of H5dump to work looks like the Command1's text was somehow invisibly modified so that H5dump does not recognize something in it!
Unbelievable sensitivity of CISSUE@ to somethings going under the carpet. It always was like this. This creates the most difficult error to catch - you may make not lethal for the code error somewhere, or even have no error, but the failure of the code to operate correctly is exposed in some other place (here - even in the completely external code!). Lost a week to debug CISSUE part and still working. Clearly some devilry lives inside of CISSUE 😃. Looks like it needs some major revision to improve stability. Will try to make a demo but afraid this will need to prepare some data files too which were so far huge in size
CISSUE is a very old FTN77 routine that was superceded by START_PROCESS@ and START_PPROCESS@.
These in turn were superceded by the Fortran Standard EXECUTE_COMMAND_LINE.
After a new process has been spawned you have no control over what happens (either it runs or it fails) unless you provide some mechanism for the process to interact and communicate with the host.
All of these routines end up calling the Microsoft API called CreateProcess. There are various approaches to inter-process communication but none of them are easy to implement. Fortran users should probably opt first for creating a new thread rather than a new process (see START_THREAD@).
EXECUTE_COMMAND_LINE works ok.
All other variants like cissue@, start_process@ etc in Help have to be marked as potentially error-prone when used with newer codes.
EXECUTE_COMMAND_LINE is preferred because it is a Fortran Standard intrinsic. Otherwise the various routines are equally safe. Very little goes on interally before a call to the Microsoft API CreateProcess.
Sometimes we are too quick to blame our tools rather than our own workmanship.
Paul, The code where i do that SISSUE@, START_PROCESS@ etc is very small and simple, it is almost impossible to make any tricky error there. The only where it is large - it is large in allocated memory and file sizes it loads. With small files all look OK, but the devilry starts with files become of few GB in size. Due to that when loading that much data code may catch some zombie (denormal) number and the code may attract some not immediately noticeable schizophrenia.
So eventually EXECUTE_COMMAND_LINE also broke... The only way all works now is by your last suggestion when i start EXECUTE_COMMAND_LINE in the additional thread.
If you want to catch this tricky undercover error, then i can try to prepare as small as possible demo. Currently it would require for you to install HDF5, so to avoid that i need to find another way to force the bug to reveal itself.
Dan
If you can make it easy for me then I will aim to look at it but it's not something that we should necessarily support.