|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mike.smartcam
Joined: 02 Aug 2014 Posts: 40 Location: Lancashire, United Kingdom
|
Posted: Fri Sep 12, 2014 8:32 am Post subject: START_PROCESS@ and CISSUE@ |
|
|
Hi group,
Does anyone have a working example of the following routines please:
START_PROCESS@,
CISSUE@
Thank you for any assistance _________________ Regards
Mike |
|
Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007 Posts: 314 Location: D�sseldorf, Germany
|
Posted: Fri Sep 12, 2014 9:50 am Post subject: |
|
|
Mike,
I prefer start_process_and_wait@. Example:
Code: | 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:
Quote: | 278) 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_TIME
All 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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Fri Sep 12, 2014 10:16 am Post subject: |
|
|
Hi Mike,
I don't iuse CISSUE@ but I do have a facility to launch Notepad or Calculator as per this example:
Code: | 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:
Code: | 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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Fri Sep 12, 2014 10:18 am Post subject: |
|
|
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 |
|
Back to top |
|
|
mike.smartcam
Joined: 02 Aug 2014 Posts: 40 Location: Lancashire, United Kingdom
|
Posted: Fri Sep 12, 2014 11:28 am Post subject: |
|
|
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?
Code: | 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 |
_________________ Regards
Mike |
|
Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007 Posts: 314 Location: D�sseldorf, Germany
|
Posted: Fri Sep 12, 2014 12:01 pm Post subject: |
|
|
Why do you want to use the old DOC type command? What do you think about the following?
Code: | 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
Last edited by Wilfried Linder on Fri Sep 12, 2014 12:28 pm; edited 1 time in total |
|
Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007 Posts: 314 Location: D�sseldorf, Germany
|
Posted: Fri Sep 12, 2014 12:06 pm Post subject: |
|
|
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):
Code: | 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 |
|
Back to top |
|
|
mike.smartcam
Joined: 02 Aug 2014 Posts: 40 Location: Lancashire, United Kingdom
|
Posted: Fri Sep 12, 2014 12:22 pm Post subject: |
|
|
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? _________________ Regards
Mike |
|
Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007 Posts: 314 Location: D�sseldorf, Germany
|
Posted: Fri Sep 12, 2014 12:36 pm Post subject: |
|
|
Hi Mike,
OK, in this case it might be the simplest way to use
Code: | integer*4 j
call cissue@('type my_text.txt',j)
|
Wilfried |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Fri Sep 12, 2014 1:20 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
mike.smartcam
Joined: 02 Aug 2014 Posts: 40 Location: Lancashire, United Kingdom
|
Posted: Fri Sep 12, 2014 1:39 pm Post subject: |
|
|
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 _________________ Regards
Mike |
|
Back to top |
|
|
mike.smartcam
Joined: 02 Aug 2014 Posts: 40 Location: Lancashire, United Kingdom
|
Posted: Fri Sep 12, 2014 2:13 pm Post subject: |
|
|
ok i've got it thanks everyone
syntax:
Code: | call cissue@('cmd /c type FSMENU.TXT',j) |
_________________ Regards
Mike |
|
Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007 Posts: 314 Location: D�sseldorf, Germany
|
Posted: Fri Sep 12, 2014 2:59 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
mike.smartcam
Joined: 02 Aug 2014 Posts: 40 Location: Lancashire, United Kingdom
|
Posted: Wed Sep 17, 2014 1:29 pm Post subject: |
|
|
Thanks everyone seem to have this working now _________________ Regards
Mike |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sat Oct 08, 2022 8:26 pm Post subject: |
|
|
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
Code: | 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 |
|
Back to top |
|
|
|
|
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
|