A user/project tool used to run a Windows console application (DOS is definitely the wrong term here) is by design for a non-interactive execution of one or more console applications with capturing the outputs written to standard output and standard error streams and display the output in an edit window or the output window in UltraEdit. Programmers use a user/project tool to run the compiler / interpreter and get its output captured to an edit window or the output window. The execution of the created executable or script with user interactions (manual input during execution) is usually done with a separate user tool as in this case capturing the output should not be done. A user working interactive with the started executable or script needs to see the output and needs to enter the input. That is not really possible with capturing the output by UltraEdit.

Programmers use therefore usually two user/project tools. The first one is for compilation of the source code to a library or executable. That is what you tried already. I suggest following changes on already existing user tool configuration:

1. Modify the command line to specify the compiler gfortran with its full qualified file name which means with drive + path + name + extension. Enclose the full qualified file name of the compiler in double quotes " if it contains a space or one of these characters &()[]{}^=;!'+,`~.
2. The first argument string passed to the compiler is the name of the active file without path. This file name should be enclosed in " which means using "%n%e" in case of the name of the active file contains in future a space or one of the special characters.
3. The third argument string passed to the compiler is the name of the active file without path and without file extension and specifies the output file name. This file name should be enclosed also in " which means using "%n" in case of the name of the active file contains in future a space or one of the special characters. If the FORTRAN compiler adds itself the suitable file extension like .exe, then it is okay to specify as name of the output file just the file name without file extension. Otherwise it would be better to use "%n.exe" as third argument.
4. The Options are correct set whereby Save all files first is usually checked only on working with multiple source code files which are compiled all at once with a single execution of a user tool which in this case does not run just the compiler for one source code file, but a make tool which runs the compiler on a set of source code files and finally the linker on no error occurred on compilation of any source code file.
5. For the Output the selection of Output to list box is usually the best choice for just compilation of a source code file as this results in getting the captured output written into the output window. If the compiler outputs a warning or an error message in a format understood by UltraEdit, it is possible to double click on the warning/error line in output window to set the caret in the source code file to the line with the incorrect code to fix it. See also the other commands offered by UltraEdit in context menu of the output window by right clicking on a line in an output window. It is even possible to navigate in source code file with pressing a hotkey (key combination) to previous or next line with an error in code according to previous/next warning/error line in output window.
6. The output option Show DOS box should not be checked on running the compiler with capturing its output. That is not necessary on compiler does not prompt the user for an input which no compiler does on running it with a correct list of arguments. The standard and error output is captured by UltraEdit nevertheless and displayed in output window after the started compiler terminated itself.
7. The option Clear output before run should be also checked with capturing the output to the output window.

A second user tool should be used for execution of a program compiled before which is a Windows GUI application or a Windows console application which requires user input during the execution.

1. The Command line is in this case just "%n.exe" and the working directory is defined with %p (never use double quotes for working directory) if the created executable is run always without any arguments.
2. Save active file and Save all files first are both not needed for just starting the executable, except there is a file edited in UltraEdit which is used by the started executable as input file. DOS program should be selected on created executable is a Windows console application, Windows program should be selected if the created executable is a Windows GUI application.
3. On tab Output it does not matter which option is selected on left side for the command output because of Capture output should be unchecked in any case on running a Windows GUI or a Windows console application with user input required during the execution. The option Show DOS box must be checked if the executable program is a console application which requires user input during the execution.

The execution of a DOS program results always in starting in background the Windows command processor cmd.exe with the option /c to close (terminate) itself once the execution of the Command line appended as argument string(s) by UltraEdit finished. The Windows command processor uses the Windows kernel library function CreateProcess to run the executable(s) specified on the command line and yes, cmd.exe searches also for executables/scripts specified just with file name using the environment variables PATHEXT and PATH. There is left to /c additionally used the cmd.exe option /U if on tab Output capturing of the output is enabled and UTF-16 is selected if the started executable is a Windows console application which outputs in Unicode with UTF-16 encoding like wmic.exe. UltraEdit for Windows v28.10 uses additionally the CMD option /s left to /c and encloses the entire command line as specified in user/project tool configuration additionally in ", except the option Show DOS box is checked. The reason is explained on running cmd /? in a command prompt window. UltraEdit starts the program directly with the Windows kernel library function CreateProcess on Windows program selected on tab Options.

I have never used it but it is possible to run the compiler with the Windows command processor instance started by UltraEdit on execution of the user tool and capture its output and on successful compilation without any warning or error start automatically a second instance of the Windows command processor to run the executable and keep this second instance of cmd.exe running even after compiled executable terminated itself to see the output of the executable and for whatever commands the user wants to run next via the second CMD instance after finishing the execution of the compiled executable.

It works to use in UltraEdit for Windows v22.20 and v23.20 the test Command line

"%SystemRoot%\System32\find.exe" "Highlight" "%ProgramFiles%\IDM Computer Solutions\UltraEdit\changes.txt" & start "Test Console" %SystemRoot%\System32\cmd.exe /D /K set

with capturing the output to the output window which results in starting cmd.exe to run find.exe to search case-sensitive for the string Highlight in the specified text file containing at least one line with Highlight, and as find.exe with terminates itself with exit code 0 for success, start one more command process with a title for the console window and run the command set and keep this second command process running, and get the output of find.exe to first standard output stream of cmd.exe started by UltraEdit captured into the output window of UltraEdit. But the output of find.exe is not captured to the output window by using this Command line in UltraEdit for Windows v28.10 although cmd.exe is started by UltraEdit v28.10 with exactly the same arguments list as with UltraEdit v22.20. UltraEdit v28.10 does not output the captured output by executed find.exe to the output window. There is only displayed the executed command line in the output window. This is a bug in my opinion of UE v24.00.0.42 to v28.10.0.154 which I have reported to IDM support by email.

However, the single command line can be used with capturing the output of the compiler into an edit window instead of the output window. So if you want to go with the single user tool solution, use the following settings in the user tool configuration:

Tab Command

Menu item name: Compile Fortran
Command line: "C:\Path to FORTRAN\Compiler\gfortran.exe" " %n%e" -o "%n" && start "Test %n.exe" %ystemRoot%\System32\cmd.exe /D /K "%n.exe"
Working directory: %p
Toolbar bitmap/icon file: full qualified file name of an image file with the icon for this user tool

Tab Options

Program type: DOS program selected
Save active file: checked
Save all files first: not checked or checked if there is a reason to save all files first

Tab Output

Command output: Replace existing selected
Show DOS box: not checked
Capture output: checked
Clear output before run: not checked
Replace selected text with: No replace selected
Handle output as: ANSI selected (most likely, depends on gfortran.exe)

It is important to select Replace existing instead of Output to list box due the issue with captured output not written to the output window on compilation was successful and so a new command process is started with running the compiled executable and keep running after finishing execution of compiled executable.

The ultimate solution with running the FORTRAN compiler and capturing its output written by UltraEdit to the output window and on successful compilation start one more command process to run the just created executable and keep this second command process running while UltraEdit writes the captured output of the compiler to the output window and becomes responsive again for user input is unfortunately not working with UltraEdit for Windows v24.00.0.42 to currently latest v28.10.0.154. It works fine with older versions like v23.20.0.42 or v22.20.0.42.

The not so good solution with the difference on writing the captured output to an edit window replacing the previously captured text in same edit window instead of the output window works with UltraEdit for Windows v24.00.0.42 to currently latest v28.10.0.154. The disadvantage is that navigating to a line in compiled source code file with an error is not so handy on writing the captured output of the compiler into an edit window instead of the output window. The navigation from one source code line in source code file producing a warning or an error during compilation by using the hotkeys Ctrl+Shift+DOWN ARROW (command Next message) and Ctrl+Shift+UP ARROW (command Previous message) after a not successful compilation is extremely helpful for programmers.

I suggest for the second user tool to run the compiled executable to use as command line "%n.exe" with the output option Show DOS box checked while the output option Capture output is not checked which makes it possible to input strings if the compiled executable prompts the user for input. But the compiled executable is nevertheless started in this case via cmd.exe started by UltraEdit with option /c and for that reason the Windows command processor closes itself after the compiled executable terminated itself which results in closing also the console window.

The second tool to run the compiled executable can be configured as follows to see a console window and keep this console window opened even after the compiled executable terminated itself.

Tab Command

Menu item name: Run compiled EXE
Command line: start "Test %n" %ystemRoot%\System32\cmd.exe /D /K "%n.exe"
Working directory: %p
Toolbar bitmap/icon file: full qualified file name of an image file with the icon for this user tool

Tab Options

Program type: DOS program selected
Save active file: not checked
Save all files first: not checked

Tab Output

Command output: Append to existing selected
Show DOS box: not checked
Capture output: not checked
Clear output before run: not checked
Replace selected text with: No replace selected
Handle output as: ANSI selected

So what happens on running this user tool with active file having the file name Fortran Test?

UltraEdit starts in the background the Windows command processor with following command line:

cmd.exe /c start "Test Fortran Test" %Systemroot%\System32\cmd.exe /D /K "Fortran Test.exe"

The started cmd.exe interprets the command line after option /c according to the rules described by the help of the Windows command processor output on running cmd /? in a command prompt window. The rules are hard to understand for a beginner in a using the Windows command processor. Many programmers fail to pass a command line correct to the Windows command processor because of not understanding the complex rules applied by cmd.exe on the argument strings after option /c (run and close) or option /k (run and keep running).

The first cmd.exe instance started by UltraEdit in background without a visible console window first processes the command line and replaces %Systemroot% by C:\Windows. There is nothing more to do and so the command line to execute now by cmd.exe is:

start "Test Fortran Test" C:\Windows\System32\cmd.exe /D /K "Fortran Test.exe"

So first cmd.exe executes its internal command start which means the Windows kernel library function CreateProcess is used to start another executable. The other executable to start is in this case C:\Windows\System32\cmd.exe which means one more command process is started by the already running cmd.exe. The usage of command start results in calling the function CreateProcess with a STARTUPINFO structure which contains the information for CreateProcess that a console window should be opened for this executable. That is the reason why now a console window is visible for the second cmd.exe started by the first cmd.exe which was started by UltraEdit without opening a console window. The lpTitle (long pointer to title string) is also used by first cmd.exe and points to the string "Test Fortran Test" which is set by CreateProcess as title for the console window.

Many Windows users think that cmd.exe opens a console window on being executed, for example on double clicking on a file with extension .bat or .cmd. But that is not true. cmd.exe on being start opens never for itself a console window. That is always the task of the process which starts cmd.exe using CreateProcess. That means that explorer.exe is responsible for showing a console window on double clicking on a batch file which is also the reason why every user can configure multiple different options for each console application started by the Windows File Explorer which most Windows users are not aware of at all. The output option Show DOS box in user/project tool configuration of UltraEdit controls if UltraEdit should start cmd.exe with using CreateProcess without or with opening also a console window by CreateProcess.

The start of the second command process with using the full qualified file name C:\Windows\System32\cmd.exe and its arguments also passed to CreateProcess works and for that reason the first cmd.exe started by UltraEdit closes itself now. The close of first cmd.exe instance is recognized by UltraEdit which results in this case without capturing anything in finishing user tool execution and UltraEdit is responsive again for user input.

The second started cmd.exe processes in the meantime parallel to the closing of first cmd.exe instance its arguments. It detects the option /D resulting in ignoring the AutoRun registry string value much too often misused by programmers and people not knowing how harmful it is to make use of the AutoRun registry string value. Next the second started cmd.exe detects the option /K and for that reason knows that it should keep running after finishing execution of the command line which are all other arguments string after option /K.

The command line to process now by second started cmd.exe for which a console window is visible as created by CreateProcess according to the data in structure STARTUPINFO defined by the first started cmd.exe is:

"Fortran Test.exe"

Well, this is nothing else than the name of an executable to run without any arguments. For that reason the second started cmd.exe runs now this executable using also CreateProcess, but this time with a STARTUPINFO structure with data informing the function CreateProcess that no console window should be opened for this console application and that the standard input, standard output and standard error streams of second started cmd.exe should be used and instead of new streams. That is the reason why everything output by the Fortran executable becomes visible in the console window of second started cmd.exe and why the input made in this console window is passed to the Fortran executable for processing it.

Finally the started Fortran executable terminates and so the second started cmd.exe could terminate too. But it does not do that because of option /K. It keeps running and waits for the next command line input by the user via keyboard (or pasted from clipboard) to process and execute. For that reason the console window remains also open for still running second cmd.exe giving the user the possibility to see all outputs of the former executed Fortran executable and of course the possibility to enter new commands to execute.