calling other programs with cissue

Hi I have the following problem: Based on a running FTN-program, I would like to start another program, which uses an input file. Thus the code is something like

call cissue@('path\calling_program path\input_file',ifail)

Then the calling_program reads the input_file using: input = cmnam() and runs. This works perfect in all cases where no blank character is in the path or name. Nowadays it is common use to make very long pathes (no problem) but also certain blanks are in the path and this leads to problems! Up to know I'm able to have blanks for the program with 'path\calling_program'. But this(' ') does not work for the input_file. The program stops because the name of the input file is only the part up to the first blank. Do somebody have an idea for a solution. Regards Werner

There's a better way:

      INTEGER FUNCTION Launch1_FN()
       INTEGER START_PPROCESS@
       IA = START_PPROCESS@('Notepad.EXE','Datafile') ! Example
       IF (IA .NE. 0) CALL POP('Failed to start Notepad')
       Launch1_FN = 1
       END
       SUBROUTINE POP(TEXT)
       INCLUDE <WINDOWS.INS>
       CHARACTER*(*) TEXT
       IA=WINIO@('%ca[For Info]cn%si*'//TEXT//'&')
       IA=WINIO@('%2nl%cn%`7bt[OK]')
       RETURN
       END 

... and it's an INTEGER FUNCTION so it can be used as a callback from a menu item or button. The error message (as written) assumes you are using Clearwin, but Start_Pprocess@ works even without.

Regards

Eddie

Thanks, this may be more elegant but leads to the same result. A path with blanks could be used via '...', e.g. 'c:\path1\p ath2\myprogram.exe'. This is not the problem. The real problem is that the program myprogram reads the inputfile with the FTN-routine CMNAM. Here, arguments are separated by spaces. Thus my inputfile e.g. c:\path1\p ath\input is separated into c:\path1\p and ath2\input. Thus an error occur like: Inputfile c:\path1\p does not exist.

A modification to 'c:\path1\p ath2\input' does not help Again the inputfile 'c:\path1\p does not exist. Regards Werner

Sorry, I misunderstood.

I have very successfully used the following code - firstly:

       INVOKED = CMNARGS@()

and then, after some intervening code the following extracts a file name from the command line and removes the double quotes I find there:

       IF (INVOKED .GE. 1) THEN
           FILEN  = CMNAM()
           FILENM = FILEN(2:130)
           DO 10 I=1,129
           IF (FILENM(I:I) .EQ. ''') FILENM(I:I)=' '
 10        CONTINUE
      ENDIF

(FILEN is CHARACTER*(130); FILENM is CHARACTER*(129) )

I go on to open the file with a standard fortran OPEN statement. However, my program never sees an explicitly typed command line, but is responding to a user clicking on a properly registered data file. Windows issues what I might best describe as a 'pseudo command line' in this case. I tried it with paths that contained blanks, and file names with blanks, and both - it works.

You will imagine my surprise when I typed a command line explicitly (in a 'DOS box'), and got the behaviour you report. In this case, the blanks appear to be used as separators to divide the command line up into 'tokens'.

I fear that you will have to re-assemble the tokens from the command line into a string (reinstating the blanks) until you have a valid path and filename combination. The good news is that FTN95 OPEN will accept a filename/path with blanks in it !

Eddie

ww,

Instead of using cmnam() I use CALL COMMAND_LINE instead, which puts the entire command line (excluding the program name) into a single character string variable.

Assuming that the command line only contains a full path name to a single file then this routine will met your needs.

Hmmm...

I didn't get any further than reading (.NET) against this subroutine in FTN95.CHM !

I have checked the idea of Eddie. It's a little bit tricky, but it works perfect. This was for my problem the solution (one program with one input file and both with path and blanks in path and names). Many thanks Werner

Hi Werner,

John Horspool's suggestion was better than mine! This sort of thing you do once per application - sometimes years apart ...

Eddie

Hi Eddie and John at the end the solution is trivial. Command_Line is very simple and fulfills perfectly my special demands. Furthermore adding/removing '...' is obsolete. Thanks a lot. Werner