請問如何在Delphi裡用API做到"Windows工作管理員"的"工作結束"功能呢？謝謝！

引言: 請問如何在Delphi裡用API做到"Windows工作管理員"的"工作結束"功能呢？謝謝！

MingLin 你好: 可以用 Win32 API TerminateProcess 達成目的 另外，以下是曾經發表過的相關文章，你先參考看看

Thanks! 目前我的程式設計如下： WH:=WinExec(pchar('App.exe'),SW_HIDE); ... PH:=GetWindowThreadProcessId(WH,nil); TerminateProcess(PH,0); 但App.exe並未被結束，請問該如何解決？謝謝！ 能夠提供一個完整的程式說明該如何用Process相關的API來設計程式嗎？

引言: Thanks! 目前我的程式設計如下： WH:=WinExec(pchar('App.exe'),SW_HIDE); ... PH:=GetWindowThreadProcessId(WH,nil); TerminateProcess(PH,0); 但App.exe並未被結束，請問該如何解決？謝謝！ 能夠提供一個完整的程式說明該如何用Process相關的API來設計程式嗎？

MingLin 你好:
(1)你利用 Win32 API GetWindowThreadProcessId 得到的只是 Process 的 ID
   並不是 Process 的 Handle，因此，當然無法結束該 Process
(2)建議你利用 Win32 API CreateProcess 的方式執行 App.exe，如果執行成功
   的話，CreateProcess 這個 function 的最後一個參數 struct
   PROCESS_INFORMATION 會傳回 Process 的 Handle(hProcess)
(3)如果想要結束 App.exe 的話，再用 TerminateProcess
(4)以下有一個 BCB 寫的範例程式碼，你先參考看看吧
   >    -- 
        

Thanks! 改用CreateProcess和TerminateProcess設計後初步測試OK，同時找到一篇Delphi的程式碼可供大家參考： http://www.delphicorner.f9.co.uk/articles/wapi4.htm 另一問題請教： 之前用WinExec可直接用SW_MINIMIZE不顯示視窗，現改為CreateProcess則應如何做到不顯示視窗呢？謝謝！

Another thinking... 之前我是用WinExec執行某一App.exe，再用SendMessage(HWnd,WM_CLOSE,0,0)結束此App.exe，但此時會跳出一個確認結束視窗，而增加操作上的困擾。請問有什麼方法可以直接結束此App.exe而不會跳出此確認視窗？謝謝！

使用CreateProcess時不顯示視窗的設定方法如下，請大家參考！ StartupInfo.dwFlags:=STARTF_USESHOWWINDOW; StartupInfo.wShowWindow:=SW_MINIMIZE;

轉貼自http://www.delphicorner.f9.co.uk/articles/wapi4.htm Using CreateProcess to Execute Programs -------------------------------------------------------------------------------- How can I properly use CreateProcess to instantiate a new process? -------------------------------------------------------------------------------- What's a Process Before I give you the code to execute a program in Windows with CreateProcess, I feel we should delve a bit into the concept of a what a process is. With Win32, Microsoft changed nomenclature to help make the distinction of new concepts more clear for developers. Unfortunately, not everyone understood it - including myself at first. In Win16 a process was the equivalent to an application. That was just fine because Windows 3.1 was (and still is) a non-preemptive multitasking system - there's no such thing as threads. But with the move to Win32 (Win95 and NT), many people have made the mistake of equating a thread to a process. It's not an unusual thing considering the familiarity with an older concept. However, threads and processes are both distinct concepts and entities. Threads are children of processes; while processes, on the other hand, are inert system entities that essentially do absolutely nothing but define a space in memory for threads to run - threads are the execution portion of a process and a process can have many threads attached to it. That's it. I won't go into the esoteric particulars of memory locations and addressable space and the like. Suffice it to say that processes are merely memory spaces for threads. That said, executing a program in Win32 really means loading a process and its child thread(s) in memory. And the way you do that in Win32 is with CreateProcess. Mind you, for backward compatibility, the Win16 calls for executing programs, WinExec and ShellExecute are still supported in the Windows API, and still work. But for 32-bit programs, they're considered obsolete. Okay, let's dive into some code. The following code utilizes the CreateProcess API call, and will execute any program, DOS or Windows. {Supply a fully qualified path name in ProgramName} procedure ExecNewProcess(ProgramName : String); var StartInfo : TStartupInfo; ProcInfo : TProcessInformation; CreateOK : Boolean; begin { fill with known state } FillChar(StartInfo,SizeOf(TStartupInfo),#0); FillChar(ProcInfo,SizeOf(TProcessInformation),#0); StartInfo.cb := SizeOf(TStartupInfo); CreateOK := CreateProcess(PChar(ProgramName),nil, nil, nil,False, CREATE_NEW_PROCESS_GROUP NORMAL_PRIORITY_CLASS, nil, nil, StartInfo, ProcInfo); { check to see if successful } if CreateOK then //may or may not be needed. Usually wait for child processes WaitForSingleObject(ProcInfo.hProcess, INFINITE); end; Okay, while the code above works just fine for executing an application, one my readers pointed out that it doesn't work with programs that include a command line argument. Why? Because CreateProcess' first parameter expects a fully qualified program name (path\executable) and nothing else! In fact, if you include a command line in that parameter, CreateProcess will do nothing. Yikes! In that case, you have to use the second argument. In fact, you can use the second parameter even for just executing a program with no command line. Given that, ExecNewprocess would be changed as follows: {Supply a fully qualified path name in ProgramName and any arguments on the command line. As the help file states: "If lpApplicationName is NULL, the first white space-delimited token of the command line specifies the module name..." In English, the characters before the first space encountered (or if no space is encountered as in a single program call) is interpreted as the EXE to execute. The rest of the string is the argument line.} procedure ExecNewProcess(ProgramName : String); var StartInfo : TStartupInfo; ProcInfo : TProcessInformation; CreateOK : Boolean; begin { fill with known state } FillChar(StartInfo,SizeOf(TStartupInfo),#0); FillChar(ProcInfo,SizeOf(TProcessInformation),#0); StartInfo.cb := SizeOf(TStartupInfo); CreateOK := CreateProcess(nil, PChar(ProgramName), nil, nil,False, CREATE_NEW_PROCESS_GROUP NORMAL_PRIORITY_CLASS, nil, nil, StartInfo, ProcInfo); { check to see if successful } if CreateOK then //may or may not be needed. Usually wait for child processes WaitForSingleObject(ProcInfo.hProcess, INFINITE); end; I know, it's a bit of complex call. And the documentation and online help aren't much help in getting information on it. I think the biggest problem people have working with the WinAPI through Delphi is that the help topics are directed towards C/C programmers, not Delphi programmers. So on the fly, Delphi programmers have to translate the C/C conventions to Delphi. This has caused a lot of confusion for me and others who have been exploring threads and processes. With luck, we'll see better documentation emerge from either Borland or a third-party source. Copyright ?1995, 1996, 1997 Brendan V. Delumpa All Rights Reserved

------
～～～Delphi K.Top討論區站長～～～