End and Execute Commands

[Dick Bottom]

I'm "new to windows". Is there any equivalent to DOS' End command in Win?
Also, is there an equivalent to DOS' Execute, where I used to stop one program
and run another, which would then start the first, etc.?

[Michael Mattias]

END [program]: No. Program ends when your entry point function (WinMain or PBMain) ends.

EXECUTE... well, no, except you can always SHELL (function), CreateProcess or ShellExecuteEx as the last statment before your entry point function ends, which gets you the same result.

But usually under Windows you don't have to worry about calling external programs, because there is so much memory available you can keep everything in one program.

MCM

[Dick Bottom]

Michael,
Thanks, for replying.
I asked because I have a business program that is all Menus. I use shell for the Menu selections. Sometimes, the shelled program seems to be interferred with.
I am so bad at Windows, I have no idea where to look. I do see an hour glass when I mouse over the background basic program.

Also, the shell statement and function look the same. What's the difference?
Dick Bottom

[Mike Stefanik]

While there's no END statement per se, there is the ExitProcess function. For example:

#Compile Exe
#Dim All

#Include "WIN32API.INC"

Function PBMain () As Long
    Local nResult As Long
    
    nResult = MsgBox("Call the ExitProcess function?", %MB_YESNO)
    If nResult = %IDYES Then
        ExitProcess(0) ' The program terminates at this point
    End If

    MsgBox "Hello, world!"

End Function

As for the SHELL statement v. function, the function returns a value which specifies the process ID for the new process (or indicates that it has failed). The statement simply attempts to execute the program, and there's no return value to your program. So you either have:

Local dwProcessId As Dword

dwProcessId = Shell("c:\foo\bar\foobar.exe")
If dwProcessId = 0 Then
    MsgBox "Unable to execute program", %MB_ICONEXCLAMATION
End If

Or

ErrClear
Shell "notepad.exe"
If Err > 0 Then
    MsgBox "Unable to execute program", %MB_ICONEXCLAMATION
End If

[Dale Yarker]

ALSO:

with SHELL statement the SHELLing program waits for the shelled to program to finish before continuing.

with SHELL function the SHELLing program continues after shelled to program starts.

For me, choosing which of those behaviers I want overrides getting the shell process ID or zero for error.

It is explained better in PB Help.

Cheers,

[Mike Stefanik]

Good point, and I forgot that you can actually tell if the SHELL statement was successful by checking the value of ERR afterwards. For more control over the process you can use CreateProcess and WaitForSingleObject instead. For those who prefer the API method, which provides more low-level information about the process:

#Compile Exe
#Dim All

#Include "WIN32API.INC"

Declare Function InternalCreateProcess Lib "KERNEL32.DLL" Alias "CreateProcessA" ( _
    ByVal lpApplicationName As Dword, _
    lpCommandLine As Asciiz, _
    ByVal lpProcessAttributes As Dword, _
    ByVal lpThreadAttributes As Dword, _
    ByVal bInheritHandles As Long, _
    ByVal dwCreationFlags As Dword, _
    ByVal lpEnvironment As Dword, _
    ByVal lpCurrentDirectory As Dword, _
    lpStartupInfo As STARTUPINFO, _
    lpProcessInformation As PROCESS_INFORMATION _
    ) As Long

Function ExecuteCommand(ByVal strCommand As String, ByRef nExitCode As Long) As Long
    Local pszCommand As Asciiz Ptr
    Local startInfo As STARTUPINFO
    Local procInfo As PROCESS_INFORMATION
    Local nResult As Long

    pszCommand = StrPtr(strCommand)
    nExitCode = 0

    startInfo.cb = SizeOf(startInfo)

    nResult = InternalCreateProcess( _
                %NULL, _
                @pszCommand, _
                %NULL, _
                %NULL, _
                %TRUE, _
                %NORMAL_PRIORITY_CLASS, _
                %NULL, _
                %NULL, _
                startInfo, _
                procInfo)

    Function = nResult
    If IsFalse(nResult) Then Exit Function

    WaitForSingleObject(procInfo.hProcess, %INFINITE)
    GetExitCodeProcess(procInfo.hProcess, nExitCode)
    CloseHandle(procInfo.hProcess)

End Function

Function PBMain () As Long
    Local nExitCode As Long
    Local nResult As Long

    nResult = ExecuteCommand("notepad.exe", nExitCode)

    If IsFalse(nResult) Then
        MsgBox "Unable to execute this command", %MB_ICONEXCLAMATION
        Exit Function
    End If

    MsgBox "The process terminated with an exit code of" + Str$(nExitCode)

End Function

For example, one advantage of using CreateProcess like this is that you can call WaitForSingleObject and provide a specific amount of time. In this example, I use %INFINITE (which is exactly what it sounds like, wait forever until the process terminates), but you could provide a timeout period in milliseconds instead. If the WaitForSingleObject function returns %WAIT_OBJECT_0 then the process terminated. If it returns %WAIT_TIMEOUT, the process is still running and your timeout period has elapsed. That would allow you to do things like warn the user about a runaway process, terminate it, etc.

[Michael Mattias]

you can actually tell if the SHELL statement was successful by checking the value of ERR afterwards

Just a 'caution' ...

"Success" to SHELL means only the program was succesfully launched; it does not tell you the SHELLed program itself 'succeeded' or for that matter that it didn't GPF.

However, you can interrogate the return code of a child process using the GetExitCodeProcess() Winapi function.

...program that is all Menus. I use shell for the Menu selections

While shelling separate programs from a "menu" program was pretty common with MS-DOS applications, it's pretty rare to find that in a Windows' application design.

E.g,..... why do think there is no support for COMMON in the PB/windows compilers?

COMMON was often used to pass things like "UserName" and "last menu selection" back and forth between the menu program and the actual applications programs, but it's not really needed anymore.


MCM