Update UI from another thread; unnecessary code?

[robert.waters]

I have a helper class that I instantiate from my UI that creates a
worker thread, processes something, and provides an event handler to
tell the caller that it has some output from that process; I would
like to update a textbox with that output.
In order to do this, however, I need to use the TextBox.Invoke()
method, because the event handler is running on another thread. But,
this creates a lot of code that looks like it should be unnecessary: a
delegate that is *only* used as as parameter to Control.Invoke(), and
the function that is passed to Invoke().
This is the code:
-------------------------------------
Form_Load()
{
Processor p = new Processor(some args);
p.OutputRecd += new
ProcessorOutputEventHandler(this.UpdateTextbox)
p.Start();
}
private delegate void DelegateRequiredForInvoke(string text);
private void UpdateTextBox(object sender, ProcessorOutputEventArgs e)
{
TextBox1.Invoke(new DelegateRequiredForInvoke(WriteToTextBox),
e.Output);
}
private void WriteToTextbox(string text)
{
TextBox1.AppendText(text);
}
-------------------------------------

Why must the function WriteToTextBox() even exist? In a non-threaded
world, I could update the textbox in the UpdateTextBox() function.
Because of threading, not only do I need an additional function, but I
need a delegate that points to that function.
It seems like, for lack of a better word, 'cruft'.

Thank you for your help,
Robert Waters

 

[Alberto Poblacion]

I have a helper class that I instantiate from my UI that creates a
worker thread, processes something, and provides an event handler to
tell the caller that it has some output from that process; I would
like to update a textbox with that output.
In order to do this, however, I need to use the TextBox.Invoke()
method, because the event handler is running on another thread. But,
this creates a lot of code that looks like it should be unnecessary: a
delegate that is *only* used as as parameter to Control.Invoke(), and
the function that is passed to Invoke().
This is the code:
-------------------------------------
Form_Load()
{
Processor p = new Processor(some args);
p.OutputRecd += new
ProcessorOutputEventHandler(this.UpdateTextbox)
p.Start();
}
private delegate void DelegateRequiredForInvoke(string text);
private void UpdateTextBox(object sender, ProcessorOutputEventArgs e)
{
TextBox1.Invoke(new DelegateRequiredForInvoke(WriteToTextBox),
e.Output);
}
private void WriteToTextbox(string text)
{
TextBox1.AppendText(text);
}
-------------------------------------

Why must the function WriteToTextBox() even exist? In a non-threaded
world, I could update the textbox in the UpdateTextBox() function.
Because of threading, not only do I need an additional function, but I
need a delegate that points to that function.
It seems like, for lack of a better word, 'cruft'.

If you have C# version 2.0 or above, you can use instead an anonymous
method, which will let you make the call in one line without all the "glue":

private void UpdateTextBox(object sender, ProcessorOutputEventArgs e)
{
TextBox1.Invoke((MethodInvoker)delegate{TextBox1.AppendText(e.Output);});
}

 

[robert.waters]

    If you have C# version 2.0 or above, you can use instead an anonymous
method, which will let you make the call in one line without all the "glue":

private void UpdateTextBox(object sender, ProcessorOutputEventArgs e)
{
  TextBox1.Invoke((MethodInvoker)delegate{TextBox1.AppendText(e.Output);});

}

Are you sure? The documentation for MethodInvoker says that the
delegate must (return void and) take no parameters.
I will try it right now, Thank you.

It worked! Thanks!
Perhaps using an anonymous method bypasses the 'take no parameters'
restriction?

Thank you for your help.

 

[robert.waters]

[...]
It worked! Thanks!
Perhaps using an anonymous method bypasses the 'take no parameters'
restriction?

That depends on your definition of "bypasses".  Using the anoymous method  
doesn't remove the restriction; the anonymous method signature _does_ in  
fact wind up taking no parameters.

But with an anonymous method, you can "capture" any variable accessible in  
the method in which the anonymous method is declared.  So rather than  
passing the string to the delegate method, the "e" method argument winds  
up captured and used within the anonymous method directly.

In that respect, the anonymous method does bypass the restriction, by  
allowing you to get data into the anonymous method without passing it.

Pete

So rather than
passing the string to the delegate method, the "e" method argument winds
up captured and used within the anonymous method directly.

Thank you for the explanation.