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?
According to MSDN
InvokeRequired
can returnfalse
even in cases whereInvokeRequired
should betrue
- namely in the case that you accessInvokeRequired
before theHandle
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 isfalse
then you are in trouble because anInvoke
/BeginInvoke
would be necessary BUT won't work robustly sinceInvoke
/BeginInvoke
check which thread createdHandle
to do their magic...Only if
IsHandleCreated
istrue
you act based on whatInvokeRequired
returns - something along the lines of: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 .