| View previous topic :: View next topic |
| Author |
Message |
ww
Joined: 25 Jan 2009
Posts: 4
|
 Posted: Mon Feb 02, 2009 3:39 pm Post subject: 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 |
|
| Back to top |
|
 |
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2402
Location: Yateley, Hants, UK
|
| Posted: Mon Feb 02, 2009 4:51 pm Post subject: |
|
|
There's a better way:
| Code: | 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 |
|
| Back to top |
|
|
ww
Joined: 25 Jan 2009
Posts: 4
|
| Posted: Mon Feb 02, 2009 8:36 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2402
Location: Yateley, Hants, UK
|
| Posted: Mon Feb 02, 2009 11:24 pm Post subject: |
|
|
Sorry, I misunderstood.
I have very successfully used the following code - firstly:
| Code: | | 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:
| Code: | 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 |
|
| Back to top |
|
|
JohnHorspool
Joined: 26 Sep 2005
Posts: 270
Location: Gloucestershire UK
|
| Posted: Tue Feb 03, 2009 10:09 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2402
Location: Yateley, Hants, UK
|
| Posted: Tue Feb 03, 2009 12:18 pm Post subject: |
|
|
Hmmm...
I didn't get any further than reading (.NET) against this subroutine in FTN95.CHM ! |
|
| Back to top |
|
|
ww
Joined: 25 Jan 2009
Posts: 4
|
| Posted: Tue Feb 03, 2009 1:03 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2402
Location: Yateley, Hants, UK
|
| Posted: Tue Feb 03, 2009 8:50 pm Post subject: |
|
|
Hi Werner,
John Horspool's suggestion was better than mine! This sort of thing you do once per application - sometimes years apart ...
Eddie |
|
| Back to top |
|
|
ww
Joined: 25 Jan 2009
Posts: 4
|
| Posted: Wed Feb 04, 2009 8:55 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
