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 

START_PROCESS@ and CISSUE@
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mike.smartcam



Joined: 02 Aug 2014
Posts: 40
Location: Lancashire, United Kingdom

PostPosted: Fri Sep 12, 2014 8:32 am    Post subject: START_PROCESS@ and CISSUE@ Reply with quote

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
View user's profile Send private message Send e-mail
Wilfried Linder



Joined: 14 Nov 2007
Posts: 314
Location: Düsseldorf, Germany

PostPosted: Fri Sep 12, 2014 9:50 am    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Sep 12, 2014 10:16 am    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Sep 12, 2014 10:18 am    Post subject: Reply with quote

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
View user's profile Send private message
mike.smartcam



Joined: 02 Aug 2014
Posts: 40
Location: Lancashire, United Kingdom

PostPosted: Fri Sep 12, 2014 11:28 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Wilfried Linder



Joined: 14 Nov 2007
Posts: 314
Location: Düsseldorf, Germany

PostPosted: Fri Sep 12, 2014 12:01 pm    Post subject: Reply with quote

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
View user's profile Send private message
Wilfried Linder



Joined: 14 Nov 2007
Posts: 314
Location: Düsseldorf, Germany

PostPosted: Fri Sep 12, 2014 12:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
mike.smartcam



Joined: 02 Aug 2014
Posts: 40
Location: Lancashire, United Kingdom

PostPosted: Fri Sep 12, 2014 12:22 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Wilfried Linder



Joined: 14 Nov 2007
Posts: 314
Location: Düsseldorf, Germany

PostPosted: Fri Sep 12, 2014 12:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Sep 12, 2014 1:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
mike.smartcam



Joined: 02 Aug 2014
Posts: 40
Location: Lancashire, United Kingdom

PostPosted: Fri Sep 12, 2014 1:39 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mike.smartcam



Joined: 02 Aug 2014
Posts: 40
Location: Lancashire, United Kingdom

PostPosted: Fri Sep 12, 2014 2:13 pm    Post subject: Reply with quote

ok i've got it thanks everyone

syntax:

Code:
call cissue@('cmd /c type FSMENU.TXT',j)

_________________
Regards

Mike
Back to top
View user's profile Send private message Send e-mail
Wilfried Linder



Joined: 14 Nov 2007
Posts: 314
Location: Düsseldorf, Germany

PostPosted: Fri Sep 12, 2014 2:59 pm    Post subject: Reply with quote

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
View user's profile Send private message
mike.smartcam



Joined: 02 Aug 2014
Posts: 40
Location: Lancashire, United Kingdom

PostPosted: Wed Sep 17, 2014 1:29 pm    Post subject: Reply with quote

Thanks everyone seem to have this working now
_________________
Regards

Mike
Back to top
View user's profile Send private message Send e-mail
DanRRight



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

PostPosted: Sat Oct 08, 2022 8:26 pm    Post subject: Reply with quote

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 Smile. 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
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
Goto page 1, 2  Next
Page 1 of 2

 
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