Question

Overview

Are there explanations for Control.BeginInvoke() to not execute a delegate that it is passed?

Code Sample

We have adopted the following pattern in our Winforms applications to safely execute UI releated work on the UI thread:

private Control hiddenControl = new Control();

private void uiMethod()
{
  MethodInvoker uiDelegate = new MethodInvoker(delegate()
  {
    Logging.writeLine("Start of uiDelegate");
    //ui releated operations
    childDialog = new ChildDialog();
    childDialow.show();
    Logging.writeLine("End of uiDelegate");
  });

  if (hiddenControl.InvokeRequired)
  {
    Logging.writeLine("Start of InvokeRequired block");
    hiddenControl.BeginInvoke(uiDelegate);
    Logging.writeLine("End of InvokeRequired block");
  }
  else
  {
    uiDelegate();
  }
}

Here, we create a control “hiddenControl” explicitly for the purpose of running delegates on the UI Thread. We never call endInvoke because it’s apparently not required for Control.BeginInvoke and we never need to return a value because our methods just manipulate UI, anyway.

While extremely verbose, this pattern seems to be a relatively well accepted solution. There is, however, some evidence that even this pattern may not work well in all situations.

Observations

I’m not ruling out an application error and blaming WinForms. After all, select probably isn’t broken. I am however at a loss to explain why a delegate may seemingly not run at all.

In our case, we sometimes observe that the “Start of uiDelegate” log message never executes in certain threading scenarios, even though the “Start of InvokeReqiured block” and “End of InvokeRequired block” execute successfully.

It’s been very hard to replicate this behavior because our application is delivered as a DLL; our customers run it in their own applications. Therefore, we can not make any guarantees how or in which thread these methods may be called.

We ruled out UI thread starvation because it is observed that the UI does not lock down. Presumably, if the UI is being updated, then the message pump is operational and available for pulling messages from the message queue and executing their delegates.

Summary

Given this information, is there anything that we can try to make these calls more bullet-proof? As previously mentioned, we have relatively little control over other threads in a given application, and do not control which context these methods are invoked.

What else can affect how delegates successfully passed to Control.BeginInvoke() execute or not?

Answer 1

According to MSDN InvokeRequired can return false even in cases where InvokeRequired should be true – namely in the case that you access InvokeRequired before the Handle of that control/form (or a parent of it) has been created.

Basically your check is incomplete which leads to the result you see.

You need to check IsHandleCreated – if that is false then you are in trouble because an Invoke/BeginInvoke would be necessary BUT won’t work robustly since Invoke/BeginInvoke check which thread created Handle to do their magic…

Only if IsHandleCreated is true you act based on what InvokeRequired returns – something along the lines of:

if (control.IsHandleCreated)
{
    if (control.InvokeRequired)
    {
        control.BeginInvoke(action);
    }
    else
    {
        action.Invoke();
    }
}
else 
{ 
    // in this case InvokeRequired might lie - you need to make sure that this never happens! 
    throw new Exception ( "Somehow Handle has not yet been created on the UI thread!" );
}

Thus the following is important to avoid this problem

Always make sure that the Handle is already created BEFORE the first access on a thread other than the UI thread.

According to MSDN you just need to reference control.Handle in the UI thread to force it being created – in your code this must happen BEFORE the very first time you access that control/form from any thread that is not the UI thread.

For other possibilities see the answer from @JaredPar .