Other behavior run from Scite (f5) or from CMD line

[pdvos]

expandcollapse popup

#include <ProcessConstants.au3>
#include <WinAPIHObj.au3>
#include <WinAPIProc.au3>
#include <WinAPISys.au3>
Global $iErrorlevel

Global $iErrorlevel

ConsoleWrite('OverWrite? Yes / No / Cancel' & @CRLF)
 $ret = _DosChoice('ABC')

 ConsoleWrite('Exit code: ' & $iErrorlevel & @CRLF)
 ConsoleWrite('Exit code: ' & $ret & @CRLF)

Func _DosChoice($sKeys)

    ; _WinAPI_CreateProcess() will be the best solution
    Local $iPID = RunWait('CHOICE /C ' & $sKeys)  ;<- tried with command /c .. no dice 
    If Not $iPID Then
        Exit
    EndIf

    ; Note, immediately open the process
    Local $hProcess
    If Number(_WinAPI_GetVersion()) >= 6.0 Then
        $hProcess = _WinAPI_OpenProcess($PROCESS_QUERY_LIMITED_INFORMATION, 0, $iPID)
    Else
        $hProcess = _WinAPI_OpenProcess($PROCESS_QUERY_INFORMATION, 0, $iPID)
    EndIf
    If Not $hProcess Then
        Exit
    EndIf

    ; Wait until the process exists, try enter "exit 6"
    While ProcessExists($iPID)
        Sleep(100)
    WEnd

    Global $iErrorlevel =  _WinAPI_GetExitCodeProcess($hProcess)
;~ ConsoleWrite('Exit code: ' & _WinAPI_GetExitCodeProcess($hProcess) & @CRLF)

    _WinAPI_CloseHandle($hProcess)
Return $iErrorlevel  <- just trying to make it go away <g>


EndFunc   ;==>_DosChoice

 I'm trying to grab the errorlevel from the command CHOICE.

If I run the above code from scite it works like a charm a dos box opens showing me ABC and if I press one of those keys it continues and returns the errorlevel.

But if I run this from the command line  the choice command doesn't exit .. it just lingers showing the key you pressed?

How can I change this behavior?  I needs to be a CLI program.

 

 

 

 

[Nine]

What OS are you running ?  I tested on Win7 and it works fine (from Scite, from explorer, from DOS console uncompiled and from DOS console compiled).

[pdvos]

Windows 10 22H2 ...

Thanks for checking .. 

[pdvos]

on server 2008 it also fails ... now all key presses aren't shown (and they shouldn't) but nothing happens but after ending the program with CRTL-BREAK all key presses are shown...  really odd...

[Nine]

Well tested it on my win10 machine, and it also works fine.  But I only run the RunWait statement with @comspec.  Could you try it alone like I do ?

[pdvos]

 Local $iPID = Runwait(@ComSpec & ' /c ' & 'choice /c ync')  gives a handle invalid ?

Maybe choice is doing something odd that messes with the cmd autoit part ...

Thanks for chipping in Nine really appreciate it.

[Nine]

RunWait does not return a PID.  It returns the exit code of the program that was run. 

If it does not work for you, you should look at a keylogger or something, because you certainly have something wrong in your environment. 

[rsn]

I tried an abbreviated version of your code:

$sKeys="ync"
Local iReturn  = RunWait('CHOICE /C ' & $sKeys)
MsgBox ( 4096 , @ScriptName , iReturn )

and it returns the 1, 2, or 3 based on the keypress.

Agreed with @Nine that something is wonky in your environment. Choice.exe lives in a couple locations on my box: 

C:\Windows\System32\choice.exe
C:\Windows\SysWOW64\choice.exe

Perhaps you'll need to path it out or use sysnative?

[pdvos]

Sorry for the late reply people,  I reinstalled my dev machine

@Nine yeah I think I messed something up that it gives that handle error.

 

I tried with the rsn code (added $ for the vars)  and yes it works compiled as GUI and yes it returns the errorlevel.

But if I compile as CUI it and run the exe via a cmd window it fails.

@rsn big question for rsn.. Did you compile as CUI ? and run via a CMD window.

 

$sKeys="ync"
Local $iReturn  = RunWait('CHOICE /C ' & $sKeys)
MsgBox ( 4096 , @ScriptName , $iReturn )

So with the reinstalled my dev machine and now tested the above code and  again it works in scite and it worked compiled as GUI and works from the CMD window.

To be sure I moved the exe file to a clean 2022 server and it works as expected.

 

But still compiled as CUI  it hangs / shows different behaviour and same on that clean 2022 server. 

So I'm not really sure it's the environment. 

 

 

[Nine]

I am afraid that CHOICE will not work in a CUI script.  You can very closely emulate it with ConsoleWrite/ConsoleRead in Win10.  With Win7 there is known issue, where you will need to use _WinAPI_ReadFile for a CON file instead of ConsoleRead.  You will need to test it on your 2022 server.

[pdvos]

Thank you very much for the confirmation Nine !!

Do you know why this happens? or is it some sort of magic trickery like cls and the stuff of Microsoft nightmares

 

 

 

[Nine]

Some console apps use special keyboard inputs.  Choice might be one of them.

[rsn]

I'm so sorry that I didn't read about your CLI requirement. 

I did kind of get it to work on a command line. Try this:

#include <AutoItConstants.au3>
$sKeys="ync"
Local $iReturn  = RunWait( 'CHOICE /C ' & $sKeys , "" , @SW_SHOW , $RUN_CREATE_NEW_CONSOLE  )
ConsoleWrite ( $iReturn )

The last arg for RunWait seems to do the trick. Otherwise it'll appear to hang. 

[pdvos]

Can confirm it kinda works

But the as it opens a new console I end up with two cmd windows

 

 

 

 

 

Edited December 7, 2022 by pdvos