Invoke method causing dead lock ....

[LamSoft]

It seems that my program is dead lock after running this sentence (bold)

private delegate void updateBuildingDetailCallBack(String key, String Value);

private void updateBuildingDetail(String key, String Value)
{
if (tabBuildings.Controls["lblBuild_Resource_" + key].InvokeRequired)
{
// This is not a UI thread, we cannot update the UI directly
updateBuildingDetailCallBack callBack = delegate(String _key, String _Value)
{
tabBuildings.Controls["lblBuild_Resource_" + _key].Text = _Value;
};
tabBuildings.Controls["lblBuild_Resource_" + key].Invoke(callBack, new object[] { key, Value });
}
else
{
tabBuildings.Controls["lblBuild_Resource_" + key].Text = Value;
}
}

When I try to debug the program, if the program first time calling the function "updateBuildingDetail", the objects of tabBuildings.Controls["lblBuild_Resource_" + key] is still need to be invoked while normally for the first time it doesn't

May I know why cause the program hang after the bolded statement?
Thanks

[Marc Gravell]

May I know why cause the program hang after the bolded statement?

Well, what causes updateBuildingDetail to get called? which thread?
How do you start this work? A BackgroundWorker? A callback? What?
If the UI thread is still waiting on a background thread to return
(which it shouldn't necessarily), then yes: this will indeed deadlock.
If the UI is available, it should process the item and return.

If you just care that it happens (not that it happens *right now*),
then just change to BeginInvoke. Also, I wouldn't start navigating the
Controls collection, as you aren't on the UI thread... I'd change this
line to simply use the local (this) InvokeRequired/Invoke/BeginInvoke;
i.e.:

if(InvokeRequired) {
BeginInvoke((MethodInvoker) delegate {
tabBuildings.Controls["lblBuild_Resource_" + key].Text = value;
});
} else {
tabBuildings.Controls["lblBuild_Resource_" + key].Text = value;
}

Note also that Invoke/BeginInvoke are safe to call from the UI thread;
if this is generally going to be called on a non-UI thread (due to the
use-case) I might even remove the "if" etc, and simply
Invoke/BeginInvoke it.

Marc

[LamSoft]

updateBuildingDetail is called by a child (non-UI) thread, which this child
thread is created by the main thread.

I found that in the child thread, the invokeRequired of
tabBuildings.Controls["lblBuild_Resource_" + key] is already true..
So I think the program do not know where is the original UI Thread....

As that UI Control is controlled by the code, such as lblBuild_Resource_01,
lblBuild_Resource_02, etc...
So I use Controls Method to change all of those label.

Thanks

[Marc Gravell]

and i think the main thread is continuously run

Meaning what? What does the code do after myThread.Start()? It should
return to the UI, letting the form paint itself, and process its
message-queue (which is necessary for Invoke/BeginInvoke). It it sits
in a tight-loop, then this approach is doomed (short of hacky hacks).

Re the arguments exception, do you get this using the MethodInvoker
(captured variables) approach? This is often a far easier way of
creating such a delegate... and *in this case* is entirely safe since
the strings are immutable, and the variables aren't updated inside the
method (there are some gotchas to look for).

Marc

[LamSoft]

Thank you very much, I solve the problem by creating another class and move
all the function to that class...
So weird~~
"Marc Gravell" <ma**********@gmail.comwrote in message
news:Ou**************@TK2MSFTNGP04.phx.gbl...

>and i think the main thread is continuously run

Meaning what? What does the code do after myThread.Start()? It should
return to the UI, letting the form paint itself, and process its
message-queue (which is necessary for Invoke/BeginInvoke). It it sits in a
tight-loop, then this approach is doomed (short of hacky hacks).

Re the arguments exception, do you get this using the MethodInvoker
(captured variables) approach? This is often a far easier way of creating
such a delegate... and *in this case* is entirely safe since the strings
are immutable, and the variables aren't updated inside the method (there
are some gotchas to look for).

Marc