Question

For instance, a thread that is a BackgroundWorker, can be cast like:

private void worker_DoWork(object sender, DoWorkEventArgs e)
    {
        System.ComponentModel.BackgroundWorker senderWorker
                = sender as System.ComponentModel.BackgroundWorker;
    } 

The code above represents what I have for my Background worker thread. I cast [sender] as a BackGround Worker – because I know thats what he is.

I can’t seem to find what I should cast it to if: instead of a Background worker, what if I had used a Process class, and executed say a DOS batch file, using:

enter code here

Process proc = new Process();
proc.FileName = “some_dos_batch_file.bat”;
proc.Exited = ProcessExited;
proc.Start();

Sorry about syntax, but when this process completes, its completion will be handled by ‘ProcessExited’ below. But What should I cast the sender arg to in THAT case – NOT a Background Worker obviously, but I’m not sure to what? I would like to use the .Results property the same as I did for the Background worker.

Thanks – sorry for the confusion.

enter code here




    void ProcessExited(object sender, EventArgs e)

    {
     }

Answer 1

I hope I have understood your question, if not, please clarify. If you are talking about threading and using the System.Diagnostics.Process then you would need to use Thread events…consider this below a simple class called TestARP that shells out to the command line using a hidden window to retrieve the MAC/IP address of the active connection, with the output of the command redirected to a stream which is appended to a stringbuilder instance:

public class TestARP
{
    private StringBuilder sbRedirectedOutput = new StringBuilder();
    public string OutputData
    {
        get { return this.sbRedirectedOutput.ToString(); }
    }
    public void Run()
    {
        System.Diagnostics.ProcessStartInfo ps = new System.Diagnostics.ProcessStartInfo();
        ps.FileName = "arp";
        ps.ErrorDialog = false;
        ps.Arguments = "-a";
        ps.CreateNoWindow = true;
        ps.UseShellExecute = false;
        ps.RedirectStandardOutput = true;
        ps.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;

        using (System.Diagnostics.Process proc = new System.Diagnostics.Process())
        {
            proc.StartInfo = ps;
            proc.Exited += new EventHandler(proc_Exited);
            proc.OutputDataReceived += new System.Diagnostics.DataReceivedEventHandler(proc_OutputDataReceived);
            proc.Start();
            proc.WaitForExit();
            proc.BeginOutputReadLine();
            while (!proc.HasExited) ;
        }
    }

    void proc_Exited(object sender, EventArgs e)
    {
        System.Diagnostics.Debug.WriteLine("proc_Exited: Process Ended");
    }

    void proc_OutputDataReceived(object sender, System.Diagnostics.DataReceivedEventArgs e)
    {
        if (e.Data != null) this.sbRedirectedOutput.Append(e.Data + Environment.NewLine);
        //System.Diagnostics.Debug.WriteLine("proc_OutputDataReceived: Data: " + e.Data);
    }
}

If you were to run this in a thread the Process’s events will still get caught (only on the thread itself), but if you’re talking about waiting for the thread to finish, look at this class code here called ThreadTestARP that runs the above class on a thread…

public class ThreadTestARP
{
    private TestARP _testARP = new TestARP();
    private ManualResetEvent _mre = new ManualResetEvent(false);
    public ThreadTestARP()
    {
    }
    public TestARP ARPTest
    {
        get { return this._testARP; }
    }
    public void Run()
    {
        Thread t = new Thread(new ThreadStart(RunThread));
        t.Start();
        this._mre.WaitOne();
        // Blocks here...
        t.Join();
    }
    private void RunThread()
    {
        this._testARP.Run();
        this._mre.Set();
    }
}

Note how the ManualResetEvent _mre is used to signal to say in the context of the thread, “right, I am done, back to the creator…”