RunErrorsFatal @extended

[this-is-me]

As RunErrorsFatal option is currently configured, it sets @error to 1 if there was an error running the program. This functionality is not always the best, especially if the user has a dos program that returns 1 for any reason (success or error). I propose that a change be made to allow @extended to be set on the runerrorsfatal instead of @error.

[Chris_1013]

I don't understand why this is necessary. The return value of a program is different to the setting of @error based on whether or not AutoIt could run the program.

[SlimShady]

Chris is right.

@this-is-me:

If AutoIt was unable to "create" the process (eg: run a dos program), it sets @error to 1 or crashes.

I don't see what this has to do with the exit code of the dos program (in your example).

[IanR]

What he means is that it would be useful to know what error, if any, the program that was launched had returned. At the moment you can tell whether it was possible to launch the program or not, and what its PID is. However, the program you Run might fail to perform its task and thus return an errorcode of its own, and this-is-me is right in that there is presently no way of telling that happened.

For example:

Run ("XCOPY c:\nonexist.doc q:\nonexistentdriveandfolder\")

will presently return an errocode suggesting that it worked, regardless of the fact that XCOPY is being told to do something impossible.

HST, errorcodes returned by commandline programs are not totally reliable anyway, XCOPY being a case in point, it sometimes returns a "success" code when that was not the case. Therefore (IMHO anyway) the time and effort involved in adding this functionality might be questionable.

Edited February 3, 2005 by IanR

[Valik]

What he means is that it would be useful to know what error, if any, the program that was launched had returned. At the moment you can tell whether it was possible to launch the program or not, and what its PID is. However, the program you Run might fail to perform its task and thus return an errorcode of its own, and this-is-me is right in that there is presently no way of telling that happened.

For example:

Run ("XCOPY c:\nonexist.doc q:\nonexistentdriveandfolder\")

will presently return an errocode suggesting that it worked, regardless of the fact that XCOPY is being told to do something impossible.

HST, errorcodes returned by commandline programs are not totally reliable anyway, XCOPY being a case in point, it sometimes returns a "success" code when that was not the case. Therefore (IMHO anyway) the time and effort involved in adding this functionality might be questionable.

<{POST_SNAPBACK}>

RunWait does. Run returns the PID because it doesn't wait for the process to finish. RunWait returns the error code because it does wait around.