Sign in to follow this  
Followers 0
this-is-me

RunErrorsFatal @extended

5 posts in this topic

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.


Who else would I be?

Share this post


Link to post
Share on other sites



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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

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 by IanR

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0