Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Managing Processes in .NET : Page 2

If you need to launch programs from within a .NET application, the Process class is the right tool. It not only allows you to start and stop a process, but it also provides detailed information about running processes.


advertisement
Terminating a Process
You have two ways to terminate a process—Kill and CloseMainWindow. The former stops execution immediately, whereas the latter simply posts a termination message to the message queue. The Kill method can cause loss of data if it reaches the process at a critical stage. You must use the Kill method if you have to programmatically terminate a program that doesn't have a graphical user interface (such as a console program or a system service). You should always use CloseMainWindow to stop GUI programs.

You may have a programming situation in which you need to spawn an external program and wait for it to terminate. By default, a spawned process runs independently from the parent. To synchronize the two so that the parent resumes when the child has completed, you use the WaitForExit method. WaitForExit is an instance-based method that requires a fresh instance of the Process class to work.

Dim p As New Process p = Process.Start("notepad.exe") p.WaitForExit()

The Start method has several overloads; some shared and one instance-based. The instance-based overload doesn't accept parameters. To specify the name of the executable to run, you need to instantiate and fill a class named ProcessStartInfo. Let's discover more about this class and process information in general.

Discover Process Information
A running process has a lot of information to show. In first place, a running process has a unique ID that identifies it throughout its whole lifetime. If the process is a GUI program, it also has a window handle and a title string. On a more technical side, the Process class maintains information about the threads managed by the process and the modules (that is, assemblies and DLLs) loaded. Process class tracks the memory footprint and returns detailed information through a variety of properties. Table 2 lists all the properties available on the Process class.

Table 2: Properties of the Process class.

Property



Description

BasePriority

Gets the base priority of the associated process.

EnableRaisingEvents

Indicates whether the Exited event is raised upon termination.

ExitCode

Returns the exit code of the process.

ExitTime

Returns the time when the process exited.

Handle

Returns the Win32 native handle of the process.

HandleCount

Gets the number of handles opened by the process.

HasExited

Indicates whether the process has terminated.

Id

Returns the unique identifier for the associated process.

MachineName

Returns the name of the computer the process is running on.

MainModule

Returns the main module for the process.

MainWindowHandle

Returns the window handle of the main window of the process.

MainWindowTitle

Returns the caption of the main window of the process.

MaxWorkingSet

Gets or sets the maximum working set size for the process.

MinWorkingSet

Gets or sets the minimum working set size for the process.

Modules

Gets the modules that have been loaded by the associated process.

NonpagedSystemMemorySize

Gets the non-paged system memory size allocated to the process.

PagedMemorySize

Gets the paged memory size.

PagedSystemMemorySize

Gets the paged system memory size.

PeakPagedMemorySize

Gets the peak paged memory size.

PeakVirtualMemorySize

Gets the peak virtual memory size.

PeakWorkingSet

Gets the peak working set size.

PriorityBoostEnabled

Indicates whether the OS must boost the process when the main window has the focus.

PriorityClass

Gets or sets the overall priority category for the process.

PrivateMemorySize

Gets the private memory size.

PrivilegedProcessorTime

Gets the privileged processor time for this process.

ProcessName

Gets the name of the executable.

ProcessorAffinity

Indicates the processors on which the threads can be scheduled.

Responding

Indicates whether the user interface of the process is responding.

StandardError

Returns the stream used to read the application's error output.

StandardInput

Returns the stream used to write the application's input.

StandardOutput

Returns the stream used to read the application's output.

StartInfo

Gets or sets the properties to pass to the Start method.

StartTime

Returns the time that the process was started.

SynchronizingObject

Gets or sets the object used to marshal the event handler calls that are issued as a result of a process exit event.

Threads

Gets the set of threads that are running in the process.

TotalProcessorTime

Gets the total processor time for this process.

UserProcessorTime

Gets the user processor time for this process.

VirtualMemorySize

Gets the size of the process's virtual memory.

WorkingSet

Gets the associated process's physical memory usage.



The Responding property returns a Boolean value that indicates whether the process is active and working. The value results from a ping operated on the process' main window. Basically, when you attempt to read the value of the property, the property's get accessor sends a Windows message to the window with a timeout of five seconds. It utilizes the SendMessageTimeout Win32 API. If the function times out then the process is considered not responding.

Since Windows Forms applications support only the single-thread apartment (STA) model, you must ensure that the thread handling the Exited event, and the thread that created the Windows Forms control you want to update, coincide.
The Process class also fires one event, Exited, when the associated process ends. This event does not automatically fire each and every time a process terminates. If you want to fire this event, turn on the EnableRaisingEvents Boolean property. This property is set to False by default.

If you decide to handle the Exited event, then you probably need to access a Windows Forms control from within the event handler to refresh the user interface. Since Windows Forms applications support only the single-thread apartment (STA) model, you must ensure that the thread handling the Exited event, and the thread that created the Windows Forms control you want to update, coincide. This is not necessarily true by default and can lead to anomalies or even exceptions. To work around this issue, you can set the SynchronizingObject property of the Process class to the Windows Forms control you're mainly interested in (or any control on the same UI form). This guarantees that the application executes the Exited event handler on the same thread managing the form.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date