Executing a Windows program during a Fortran run

[Paulo_M_]

Hello everyone,

I am working on an optimization code, in which an external program should provide a data file, to be read by Fortran. My question is: how could I execute the external program during the Fortran run?

Thanks,

Paulo

[DavidWhite · Accepted solution]

Paulo,

You can call any command using SYSTEMQQ, which takes as an argument the command that you would use in a command or batch file.

Obviously, you would need to make sure your Fortran program closes any files needed, then you can call the program with a statement like

CALL SYSTEMQQ("C:\foldername\myprogram.exe argument1 argument2")

Then, when the program has completed, you can open the files to be analysed by your Fortran program.

Regards,

David

[Steven_L_Intel1]

Or if you have the version 15 compiler, use the standard procedure EXECUTE_COMMAND_LINE.

[Paulo_M_]

SYSTEMQQ function worked quite well. Thanks a lot!

[Paulo_M_]

A new issued appeared now. My code also generates a text file that is read by the external program as an input. Some of its lines contain external program keywords, and there must not be any blank space in the beginning of such lines.

What happens is that I declare these keywords as strings and, by default, Fortran prints them following a blank space. It obviously leads to an error running the external program. I would appreciate you could give suggestions to fix that.

Thanks again,

Paulo

[Steven_L_Intel1]

Don't use list-directed formatting (FMT=*) to do your writes - use an explicit format.

[ali_z_1]

hello
I want to call matlab program within my fortran code. I have google about this but can't figure out how should I write the code. for example I just want to run matlab program. is the below code is true?
-------------------------------------
program A
implicit none

call SYSTEMQQ('C:\Program Files\MATLAB\R2015b\bin\matlab.exe')

end program A

-----------------------------------------------------

and I have tried the below one:

---------------------------------------------------------------------------------------------------------------

 program B
 USE IFLPORT
LOGICAL (4) RESULT
RESULT = SYSTEMQQ('c:\program files\MATLAB\R2015b\bin\matlab.exe')
end program B

---------------------------------------------------------------------------------------------------------------

but there is no sign of matlab!!

my windows is win10/64bit and my compiler is Intel 11.1 and I debug the code with Microsoft Visual Studio 2008.

I am beginner and I am confused with this.

[Steven_L_Intel1]

You probably don't want to call Matlab this way - typically you are trying to ask Matlab to do something for you.  You can test your example by substituting the path to NOTEPAD.EXE and see if that works.

I suggest you consult the Matlab documentation to see how you are supposed to do whatever it is you're looking for.

[dboggs]

Problems apparently occur with SYSTEMQQ (and others) if the path contains space characters.

I need my program to launch Microsoft Wordpad. This typically occurs in the directory C:\Program Files\Windows NT\Accessories. When I try calling SYSTEMQQ ('C:\Program Files\Windows NT\Accessories\Wordpad.exe') I get the error 'C:\Program...' The same thing occurs using the alternative function SYSTEM. But, using the alternative function RUNQQ works.

I can't tell from the documentation what the finer points are distinguishing these three functions. Is there any reason in general to favor SYSTEMQQ or SYSTEM in deference to RUNQQ?

Also, it is probably risky to assume the above directory. Inquiring the properties of Wordpad.exe on my desktop, I find that the target location is "%ProgramFiles%\Windows NT\Accessories\wordpad.exe". This seemed a good idea, but it doesn't work with any of the three functions.

I can also put a copy of the file Wordpad.exe in a pre-determined directory, such as the one from which my application is launched. Then the function call is simply SYSTEMQQ ('Wordpad'). This works with all three functions, but when I distribute the application I really prefer to not have to instruct the users to configure this setup.

What's the best way to do this?

[DavidWhite]

You may find that placing an extra set of quote marks around the program name may work, e.g.

"'C:\Program Files ... '"

Windows probably won't see the outer set of quotes and if a quoted string is required to find the program because of the spaces, you need an additional set of quotes.

In the string above, it's hard to see what I typed, but it is doublequote/singlequote/......./singlequote/doublequote

Regards,

David

[jimdempseyatthecove]

You cannot include macros in command line arguments to CMD. In addition to what David suggested about enclosing the double quote within single quote (apostrophe), you will have to read the environment variable of interest (GET_ENVIRONMENT_VARIABLE), trim the trailing spaces, then concatenate with the remainder of your intended path, including " characters. If you want to use environment variables, then have your program write a .BAT file containing the command lines, then run the .BAT file.

You cannot assume the system disk is "C:".

Example: I did a fresh install on my wife's system onto a blank HD and inadvertently forgot to remove a USB hub prior to install. This resulted in drives C,D,E,F,G being consumed and the system now boots Windows to H: Due to it taking about a day to perform the install (XP), years worth of updates, Office, years worth of updated, I decided to leave it on H:.

Jim Dempsey

[Steven_L_Intel1]

May I suggest that instead of trying to open Wordpad, you consider using ShellExecute to open the file as if it had been double-clicked? I assume this is some sort of document (.rtf or similar). See here for more details.

[dboggs]

David: The dual quotes method works, but I found only so if the inner quotes are double and the outer quotes are single; i.e single/double/command string/double/single.

Jim: I agree that assuming C: is risky and not good practice. I may experiment with reading the environment variable. But I'm leaning towards just requiring a copy of Wordpad.exe to be in a know place, and if it fails, allow user to browse for it.

Steve: Yes I have used this suggestion before with great success, whenever I wish to launch the same application that the user has already registered for a double-click. But this time I do not want that app to launch. For example, my present project typically launches an app to view and edit a .txt file. The user is likely to have such files registered to open with Textpad or Notepad. By default these do not enforce word wrapping. I need the txt file to open in a word wrapped environment. Hence Wordpad.

All: I am still left with the choice of using the function SYSTEM, SYSTEMQQ, or RUNQQ. I was hoping to get some advice on which is best, or most portable, or info on the relative merits and behavior of these so that an (arbitrary) choice now does not come back to bite me in the future.

[jimdempseyatthecove]

CHARACTER*500 :: ProgramFiles
CHARACTER*500 :: WordPad
LOGICAL :: WordPadFound

...

CALL GET_ENVIRONMENT_VARIABLE("ProgramFiles",ProgramFiles)
WordPad = '"' // TRIM(ProgramFiles) // '\Windows NT\Wordpad.exe"'
INQUIRE(File=WordPad, EXISTS=WordPadFound)
IF(WordPadFound) THEN
... ! run or whatever
ELSE
... ! what you do when WordPad not found
ENDIF

Additional note.

If you desire to pop-up WordPad containing your output file .AND. have your program continue to run while WordPad is open, then consider running the program "START", with appropriate options and using WordPad as the program to start and your file name to edit as the next arg.

You can get the options for START by entering "START /?" from the command line.

Jim Dempsey

[Steven_L_Intel1]

None of the above - I would use EXECUTE_COMMAND_LINE for most portability, as it is standard Fortran.

But guess what? You can use ShellExecute to "open" wordpad.exe (with parameters) and it will do it, without your needing to find where it is.

[dboggs]

OK, I guess I'm running into the need to upgrade. I work on two different computers; one has Fortran 11 and one has Fortran 13. The ver 13 machine has GET_ENVIRONMENT_VARIABLE but not EXECUTE_COMMAND_LINE (I think that came w ver 15?). The ver 11 machine has neither. Until I manage to upgrade both machines I will find a non-portable way to get by.

Thanks to all for the very useful help.

[Steven_L_Intel1]

Why not use ShellExecute? That will work on all of them. The disadvantage is that you can't wait for the external program to finish.

[dboggs]

Because, based on your writeup in the link provided, and also as I have used it before, I thought it was only useful for launching an application according to the default double-click configuration on the target file. As explained above (#13), I don't want that in this case.

The example I have is

      i4 = ShellExecute ( &
         hwnd = NULL, &
         lpOperation = 'open'C, &
         lpFile = trim (filespec_pdf) // CHAR(0), &
         lpParameters = NULL_CHARACTER, &
         lpDirectory = NULL_CHARACTER, &
         nShowCmd = SW_SHOWNORMAL)
      IF (i4 <= 32) THEN
         WRITE (*, *) "Error ", i4, " opening file"
         STOP
      END IF

where filespec.pdf is the name of a target pdf file; ShellExecute will open the file using whatever the computer's default program is. In the present case, I need to open a .txt file specifically using Wordpad, NOT the default program. Is this a simple modification to the above example?

[jimdempseyatthecove]

How about:

      i4 = ShellExecute ( &
         hwnd = NULL, &
         lpOperation = 'open'C, &
         lpFile = 'WordPad.exe'C, &
         lpParameters = trim (filespec_txt) // CHAR(0), &
         lpDirectory = NULL_CHARACTER, &
         nShowCmd = SW_SHOWNORMAL)
      IF (i4 <= 32) THEN
         WRITE (*, *) "Error ", i4, " opening file"
         STOP
      END IF

Jim Dempsey

[Steven_L_Intel1]

As Jim suggests, you can open an EXE and it will do so. I'm not entirely sure how the shell locates wordpad when it's not in PATH, but it worked for me. I see that there is a registry key HKEY_CLASSES_ROOT\Applications that lists a bunch of "known applications", including Wordpad.

[dboggs]

Thanks Jim for the slight modification example. It works fine, and comparing the two examples I now have goes a long way to documenting and understanding how ShellExecute works.

I still have a portability concern. ShellExecute takes care of the problem of various users with different software confiruartions in the Windows world, but what about other OS such as Linux? ShellExecute introduces one more thing I would have to change in the code, since it is an API routine and not standard Fortran. Would RUNQQ, SYSTEM, or SYSTEMQQ be better in this regard?

Some of my applications have been in use around here for 35 years, spanning DOS (and even earlier) and various issues of Windows. I hope that some of the ones I am developing now have a similar longevity. Modifying them for various OS can certainly be a pain, but often better than rewriting from scratch.