Announcement

Collapse
No announcement yet.

End and Execute Commands

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • End and Execute Commands

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

  • #2
    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
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      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

      Comment


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

        Code:
        #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:

        Code:
        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

        Code:
        ErrClear
        Shell "notepad.exe"
        If Err > 0 Then
            MsgBox "Unable to execute program", %MB_ICONEXCLAMATION
        End If
        Last edited by Mike Stefanik; 16 Mar 2008, 02:33 AM. Reason: Change some code after the fact to avoid confusion
        Mike Stefanik
        sockettools.com

        Comment


        • #5
          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,
          Last edited by Dale Yarker; 16 Mar 2008, 12:19 AM.
          Dale

          Comment


          • #6
            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:

            Code:
            #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.
            Last edited by Mike Stefanik; 16 Mar 2008, 02:39 AM. Reason: Added some code for CreateProcess, just for fun
            Mike Stefanik
            sockettools.com

            Comment


            • #7
              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
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment

              Working...
              X