WinForms interthread modification

Question

Whenever I want to modify a winform from another thread, I need to use

->Invoke(delegate, params)

so that the modification occurs in the winform's own thread.

For every function that needs to modify the gui, I need another delegate function.

Is there some scheme which allows me to limit the number of delegate functions needed? I have a controller class which handles the whole gui in one spot, I've thought about reusing delegates but that smells badly.

I think that my question can apply to all languages where winform can run

Answer 1

Look at using the existing System.Action<T> and System.Func<T,T> delegates:

control.Invoke(
    new Action<int, string>(
        (i, s) => MessageBox.Show(String.Format(s, i))), 1, "{0}");
int iret = (int) control.Invoke(new Func<int, int>(i1 => i1 + 1));

Answer 2

If you're using C# 3, you can use lambda, and in C# 2, use anonymous delegates. These simplify the syntax when there's no need to reuse the behavior. One thing I always do is to do the synchronization in the form code, not in the controller. The controller shouldn't be bothered with these sort of "plumbing" problems that are more specific to the technology than to the controller logic.

public void ResetFields()
{
    // use "delegate" instead of "() =>" if .Net version < 3.5
    InvokeOnFormThread(() => 
    {
        firstInput.Text = Defaults.FirstInput;
        secondInput.Text = Defaults.SecondInput;
        thirdChoice.SelectedIndex = Defaults.ThirdChoice;
    });
}

// change Action to MethodInvoker for .Net versions less than 3.5
private void InvokeOnFormThread(Action behavior) 
{
    if (IsHandleCreated && InvokeRequired)
    {
        Invoke(behavior);
    }
    else
    {
        behavior();
    }
}

As a practice, make all public methods in your form call "InvokeOnFormThread." Alternately, you could use AOP to intercept public method calls on your form and call "InvokeOnFormThread," but the above has worked well enough (if you're consistent and remember to always do it on public methods on the form or UserControls).

Answer 3

I recall turning off the checks and manually verifying that every call I used was safe.

A surprising number of them could be called cross-threaded because of the guarantee I had about where certain threads were (semaphores) or because they called underlying API functions that could be used on other processes.

I still ended up with lots of invokes, usually on context objects so I could MethodInvoker.

I also encountered a nasty bug in Control.Invoke, driving me to write a custom invoker library.

Answer 4

The answer of Michael Meadows is a good example of how to centralize logic of updating a GUI form.

Concerning performance (which we can easily become obsessed over) of invoking numerous delegates to synchronize the front end, a while ago, I wrote software that outperformed an equivalent C++ (native) windows application in terms of GUI synchronization! And that was all thanks to BeginInvoke and the ThreadPool class.

Using Action<> and Func<> delegates and the ThreadPool class are beneficial too and consider the general Invoke pattern (exposed by Michael above):

public void TheGuiInvokeMethod(Control source, string text)
{
   if (InvokeRequired)
      Invoke(new Action<Control, string>(TheGuiInvokeMethod, source, text);
   else
   {
       // it is safe to update the GUI using the control
      control.Text = text;
   }
}

where TheGuiInvokeMethod would really be located in a form or other control.