Reasons that Control.BeginInvoke would not execute a delegate?

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 .

Answer 2

There are a couple of reasons for which a BeginInvoke call can fail.

1. The control and all of it's parents don't have an internal handle created. This would cause an exception at the call site
2. The control posted the delegate but was destroyed before it was actually run on the UI thread
3. The UI thread stops pumping messages (usually thread ends)

It sounds like it's very possible that #2 is causing your grief here. I've had this problem a couple of times developing winform applications. It caused me enough grief that I switched from Control.BeginInvoke to SynchronizationContext.Current.Post . The SynchronizationContext.Current instance will live for the life time of the UI thread in a WinForms app and IMHO is a bit more reliable than invoking off of a specific Control

Answer 3

You are probably throwing an exception in your first Logging call. I would suggest taking a look at the TPL, though (if you are using .Net 4.0). Tasks can make your code much more readable, and you can do something like the following

Task t = Task.Factory.StartNew(()=>{...Do Some stuff not on the UI thread...});
Task continuationTask = t.ContinueWith((previousTask)=>{...Do your UI stuff now 
         (let the Task Scheduler deal with jumping back on the UI thread...},
    TaskScheduler.FromCurrentSynchronizationContext());

Then, you can also easily check if any of the tasks have exceptions via continuationTask.Exceptions.