Retrieving Exit Codes (Error levels) from a command line utility 3

[Rajesh Karunakaran]

Hi Team,

I have a command line utility to send emails. After its execution it returns Exit Codes or Error Levels from which we would know if it went well or the kind of error it generated.

I am executing the utility from within VFP using ShellExecute. Everything is fine. However, I am not able to find a way to retrieve the Exit Code returned by the utility. I have seen a few write-ups but they're all regarding setting up a batch file. But, I think, to involve a batch file is not my appropriate solution as I am calling this utility in the middle of a functional process running inside a form.

Thanks in advance for the suggestions/advises.

Rajesh

 

[Olaf Doschke]

Once more today,

http://fox.wikis.com/wc.dll?Wiki~ProcessExitCode

describes how to start a process and wait for it finishing including getting its exit code.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Rajesh Karunakaran]

Hi Olaf,

Thank you very much. Exactly what I was looking for I hope.
Will check it and let you know.

I was wondering why you're saying 'Once more today' but then saw the post below mine about 'Checking and wait for checking to finish...'.
Sorry, I had not seen that, or may be missed it because the title appeared about something else.

Thank you,
Rajesh

 

[Olaf Doschke]

No need to mention, it's clear you only search for an answer and when you don't find it ask your question and look into your own thread.
It's just funny how such coincidences happen quite often.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Rajesh Karunakaran]

Dear Olaf,
Yes, you're right! At least in my case ;-)

By the way, I found a code using 'WScript.Shell' which also has a provision to wait for the called routine to finish. That was much more simpler than 'ShellExecute' to implement. Below is the function I am using.

LOCAL oShell, lErrCode
oShell = CREATEOBJECT("WScript.Shell")
*/ pCmd = Command to execute
*/ 0 = Hide run window
*/ 1 = Wait till execution exists.  This is required to get the ERRORLEVEL returned on lErrCode variable
lErrCode = oShell.Run(pCmd, 0, .T.)
oShell = null 
RELEASE oShell
RETURN lErrCode

It's working perfectly in my Windows 10 64 bit laptop. Need to check in older versions and 64/32 bit combinations.
By the way, are there any known dis-advantages of 'WScript.Shell' as such compared to 'ShellExecute'?

Thank you,
Rajesh

 

[Rajesh Karunakaran]

Hi Olaf and all others,

The code I posted above works like a charm in my Win 7 32bit system too!

Thanks,
Rajesh

 

[Olaf Doschke]

Yes, this solution was discussed in thread184-1790999

But Koen Pillar had some problem with it. The more complicated CreateProcess/WaitForSingleObject is not depending on any OLE class and will also work on systems restricting shell scripting. You can hide the complexity by defining your own class or functions library with a RUN method/function hiding all that and are better off.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Rajesh Karunakaran]

Olaf,

I see that there is obviously a point in what you're saying. I will try to create a class (as given in the link you posted in the beginning) and to use ShellExecute instead of WScript.Shell (a swap again !)

Thanks
Rajesh

 

[Mike Lewis]

are there any known dis-advantages of 'WScript.Shell' as such compared to 'ShellExecute'?

The wscript method depends on the Windows Scripting Host (WSH) being installed and activated. I've often read that system administrators sometimes disable WSH for security reasons. That said, I've never come across a case of that actually happening, and I'm not sure why it should be an issue. But it is the reason that ShellExecute() might be the preferred method.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, it's still a dependency you can avoid using CreateProcess/WaitForSingleObject.

Notice, Rajesh, the best equivalent to Wscript.Shell.Run() is not ShellÉxecute, ShellExecute doesn't tell you a process id of the process it started so you can't wait for it to exit and don't get the exit code, the only thing ShellExecute also offers is setting window state. The wiki link is about usage of CreateProcess/WaitForSingleObject.

There's more to it, when you use CreateProcess you may also use the stdin/stdout/err pipes and other interprocess communication methods (as far as the other process supports them).

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Rajesh Karunakaran]

Mike,

Very clear! Thanks.

Rajesh

 

[Rajesh Karunakaran]

Olaf,
Thank you for that explanation on 'CreateProcess / WaitForSingleObject'.
I got it.

Rajesh

 

[Mike Lewis]

the only thing ShellExecute also offers is setting window state

For what it's worth, wscript.shell.run also offers the window state - in its second parameter. As far as I can see, these values are the same as with ShellExecute().

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Yes, I said so, but ShellExecute does not offer to wait for the process to finish, CREATEPROCESS/WAITFORSINGLEOBJECT does,
Therefore, Mike, ShellExeecute is NOT the analog function to replace oShell.Run if you want MORE than control the window size/visibiliy.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

ShellExeecute is NOT the analog function to replace oShell.Run if you want MORE than control the window size/visibiliy.

I never said otherwise, Olaf. I was simply picking up your point about the window state.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, and I said "the only thing ShellExecute also offers is setting window state" in the sense that it doesn't offer the other important feature asked by the thread title: To wait for the exit code.

But you recommended using ShellExecute when not using Wcript.Shell.Run(), but ShellExecute lacks that feature and so it's the wrong recommendation.

I hope that makes clear now, why I didn't second your recommendation of ShellExecute as alternative, you forgot what is asked for, ShellExecute does not suffice for that.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name