asynchronous programming question

[Chris]

Hello,

With asynchronous programming :

Why does the callback-function (running in a worker thread) may not update
the state of a control on the main-form ?

The docs say that you must use a MethodInvoker instead as in following
example :

Private Sub CallBtn_Click(B yVal sender ...) Handles CallBtn.Click

webServiceObj = New MyDatabaseWSCla ss()|
Dim delCB As New AsyncCallback(A ddressOf MyCallBack)
aResult = webServiceObj.B eginConnectToDB (CInt(txtSecond s.Text), delCB,
Now)

End Sub

Private Sub UpdateUI()
OutputLabel.Tex t = "Async: Web service call complete."
End If

Private Sub MyCallBack(ByVa l result As IAsyncResult)
If webServiceObj.E ndConnectToDB(r esult) = True Then
DisplayMessage( result)
End If

' following is NOT allowed although it works fine ?????
OutputLabel.Tex t = "Async: Web service call complete."
Dim mi As New MethodInvoker(A ddressOf Me.UpdateUI)
Me.BeginInvoke( mi)
End Sub

Any ideas ?

Thank you

Chris

[Aravind C]

Hi Christian,

When you receive an asynchronous callback, it is recommended
that you always update the control from the same thread in which
the control was created because windows forms controls are _not_ threadsafe.

Typically, if you are updating controls from asynchronous callback methods
that are not executing in the same thread in which the control was created,
use Control.Invoke( ) passing the delegate that updates the control.

You can aso use Control.InvokeR equired to check if the thread is
the same thread in which your control was created, and then accordingly
decide whether you need to call Control.Invoke( ).

Some C# code shown below (same semantics apply to VB.NET):

if( ! MyControl.Invok eRequired)
{
this.AddItemToC ontrol(item);
else
{
MyControl.Invok e(new AddItemDelegate (this.AddItemTo Control, new Object[]
{item}));
}

Regards,
Aravind C
"Chris" <ch********@pan dora.be> wrote in message
news:ci******** ***********@pho bos.telenet-ops.be...

Hello,

With asynchronous programming :

Why does the callback-function (running in a worker thread) may not update
the state of a control on the main-form ?

The docs say that you must use a MethodInvoker instead as in following
example :

Private Sub CallBtn_Click(B yVal sender ...) Handles CallBtn.Click

webServiceObj = New MyDatabaseWSCla ss()|
Dim delCB As New AsyncCallback(A ddressOf MyCallBack)
aResult = webServiceObj.B eginConnectToDB (CInt(txtSecond s.Text), delCB,
Now)

End Sub

Private Sub UpdateUI()
OutputLabel.Tex t = "Async: Web service call complete."
End If

Private Sub MyCallBack(ByVa l result As IAsyncResult)
If webServiceObj.E ndConnectToDB(r esult) = True Then
DisplayMessage( result)
End If

' following is NOT allowed although it works fine ?????
OutputLabel.Tex t = "Async: Web service call complete."
Dim mi As New MethodInvoker(A ddressOf Me.UpdateUI)
Me.BeginInvoke( mi)
End Sub

Any ideas ?

Thank you

Chris

[Jon Skeet [C# MVP]]

Chris <ch********@pan dora.be> wrote:

With asynchronous programming :

Why does the callback-function (running in a worker thread) may not update
the state of a control on the main-form ?

Only the UI thread should update the UI - keeping the UI single-
threaded itself makes it much simpler (you don't get two events
occurring at the same time, or two threads trying to update the same
control, etc). The Invoke/BeginInvoke methods make executing the update
on the UI thread simple.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Fred Mellender]

If the question is "Why did the designers not make controls thread safe",
one can only speculate:

In order to make controls thread safe there would have to be locking and
unlocking on all code that made use of the controls. This would make the UI
code in the Framework much more complicated and possibly less efficient.
More importantly, the users would have to worry about deadlocks in the code
they write. This has the potential to stall the UI and might be very
difficult to debug and/or to write correct user code.

IMHO it is much easier to follow the discipline of using Invoke than it
would be to understand the cause and cures of various deadlock problems
among the many UI controls being accessed by multiple threads.

But one can only speculate......

"Chris" <ch********@pan dora.be> wrote in message
news:ci******** ***********@pho bos.telenet-ops.be...

Hello,

With asynchronous programming :

Why does the callback-function (running in a worker thread) may not update
the state of a control on the main-form ?

The docs say that you must use a MethodInvoker instead as in following
example :

Private Sub CallBtn_Click(B yVal sender ...) Handles CallBtn.Click

webServiceObj = New MyDatabaseWSCla ss()|
Dim delCB As New AsyncCallback(A ddressOf MyCallBack)
aResult = webServiceObj.B eginConnectToDB (CInt(txtSecond s.Text), delCB,
Now)

End Sub

Private Sub UpdateUI()
OutputLabel.Tex t = "Async: Web service call complete."
End If

Private Sub MyCallBack(ByVa l result As IAsyncResult)
If webServiceObj.E ndConnectToDB(r esult) = True Then
DisplayMessage( result)
End If

' following is NOT allowed although it works fine ?????
OutputLabel.Tex t = "Async: Web service call complete."
Dim mi As New MethodInvoker(A ddressOf Me.UpdateUI)
Me.BeginInvoke( mi)
End Sub

Any ideas ?

Thank you

Chris

[Richard Grimes [MVP]]

Fred Mellender wrote:

If the question is "Why did the designers not make controls thread
safe", one can only speculate:

The reason is that windows messages queues are thread based. Unless .NET is
changed to do away with the dependence on windows messages for UI code,
you'll always have this issue. Avalon in Longhorn is supposed to get rid of
this dependence on thread-based message queues, but I haven't done enough
tests to verify this.

Richard
--
my email ev******@zicf.b et is encrypted with ROT13 (www.rot13.org)