2

A simple VBScript containing the single line wscript.quit(2), called from a batch script does not pass the quit parameter value into the batch errorlevel variable as it should - the batch file only echos the default error level (0).

I recently uninstalled VB6 (necessary for clean installation of VB.net) and I think this may be, at least, part of the problem. In building a work-around to pass the results of a VBScripting message box to a calling batch file, I found that the scripting file system object (scrrun.dll) had been unregistered by the uninstallation and it was necessary to re-register it to instantiate the object. I'm wondering if there is some other dependency which is required by wscript.exe to give the quit function access to the batch error level variable.

I ran wscript.exe under Dependency Walker for the aforementioned one line VBScript and the only error message I got during the execution was the following:

GetProcAddress(0x755C0000 [MSCTFIME.IME], "ImeGetImeMenuItems") called from "IMM32.DLL" at address 0x76397354 and returned NULL. Error: The specified procedure could not be found (127).

The script terminated with the proper quit code (2).

The dll mentioned exists in the System32 folder with WScript and is unregisterable.

I'm running WinXP with all the latest updates.

Any ideas would be appreciated.

aphoria
  • 19,796
  • 7
  • 64
  • 73
Shadeclan
  • 173
  • 2
  • 14
  • 1
    Side note, VB6 and VB.NET coexist just fine. They are wholely unrelated development environments. – tcarvin Oct 18 '11 at 17:04
  • 1
    I tried replicating what you described and it worked for me. Can you show us your batch file code? – aphoria Oct 18 '11 at 17:09
  • for me too. Maybe you are invoking wscript thru a secondary CMD? – PA. Oct 18 '11 at 17:19
  • 1
    Why the goofy extraneous parens around the value? – Bob77 Oct 18 '11 at 20:29
  • tcarvin: Here in our shop, everyone who has installed vb.net has trashed their vb6 installation. We found it better to just uninstall it. – Shadeclan Oct 19 '11 at 13:44
  • aphoria / PA.: I expected it to work for others who tried it - I think there is a problem with my configuration and I was hoping that someone else who had a similar problem would also have a solution. – Shadeclan Oct 19 '11 at 13:45
  • Bob Riemersma: Sorry, Bob - just habit. – Shadeclan Oct 19 '11 at 13:45

1 Answers1

4

Windows GUI programs aren't meant for console use; so they most often return False == 0 to the OS. Wscript.exe is such a program. If you want to use a .vbs from a .bat/.cmd/.exe console program, call it via Cscript.exe.

Evidence for Bob:

type el.vbs
WScript.Quit 2 ' no () when calling a Sub

echo %ERRORLEVEL%
0

cscript el.vbs

echo %ERRORLEVEL%
2  <======= cscript.exe sets ERRORLEVEL

type el.vbs
WScript.Quit 2 ' no () when calling a Sub

echo %ERRORLEVEL%
0  <======= ERRORLEVEL is (re)set to 0

wscript el.vbs

echo %ERRORLEVEL%
0  <======= wscript.exe does not set ERRORLEVEL

QED for VBScript 5.7.16599 * cscript 5.7

Update: Thanks to Bob's comment, I found

this correct explanation and remedy

evidence:

echo %ERRORLEVEL%
0

start /wait wscript el.vbs

echo %ERRORLEVEL%
2

So even Windows GUI programs can/will report status by returning an appropriate value from _tWinMain - you'll just have to /wait (resp. .Run( sCmd, nShow, True ) to pick it up.

Community
  • 1
  • 1
Ekkehard.Horner
  • 38,498
  • 2
  • 45
  • 96
  • 1
    Ekkehard Horner: I had high hopes that you were on to something but using START with the wait parameter doesn't work for me. Like I said, this is a configuration problem. I have seen other examples where the error level is returned properly, whether the script is called by wscript or cscript. – Shadeclan Oct 19 '11 at 14:15