Make Thread-Safe Calls to Windows Forms Controls

Hello

I want to get the value of a property of a control from a thread other than the
thread the control was created on, as far as I can see this is not the same as
invoking an operation on a control on a different thread I have used the
following code as per the guidance in the msdn documentation to invoke an
operation on a control from a thread other than which it was created

delegate void SetFormCursorCallback(Cursor cursor);

private void SetFormCursor(Cursor cursor)
{
if (this.InvokeRequired)
{
SetFormCursorCallback d = new
SetFormCursorCallback(SetFormCursor);
this.Invoke(d, new object[] { cursor });
}
else
{
this.Cursor = cursor;
}
}

What would I do if I wanted to access the Cursor property of the form and return
it to the caller on a different thread?

What techniques can I employ to do this?

Is there a way to make a synchronous call using a delegate that executes on a
different thread and then returns a value to the calling thread?

Thank you

Alex

i think you can just access the property directly. as long as you
don't cause any changes to the UI which you are aware of already.
at least i have done this without any visible side-effects. i know you
can get away with bad multi-threading but you will sometimes see
strange things happening... this has never happened to me just by
reading a property of a control that was created on another thread.

tim

"Tim_Mac" <mackey.tim@gmail.com> wrote in message
news:1139564099.602272.73630@g43g2000cwa.googlegroups.com...
|i think you can just access the property directly. as long as you
| don't cause any changes to the UI which you are aware of already.
| at least i have done this without any visible side-effects. i know you
| can get away with bad multi-threading but you will sometimes see
| strange things happening... this has never happened to me just by
| reading a property of a control that was created on another thread.
|
| tim
|

This is true, but (unfortunately) in v2 of the framework, you will get an
'illigal cross-thread call' exception thrown on you in debug mode. That
means that all cross-thread accesses to UI elements are considered bad
practice.

Willy.

if we're talking .net 2.0, i would use the BackgroundWorker class and
pass in the cursor as the argument. if you are already using the
argument parameter, then send in an object array as the argument to the
RunWorkerAsync method, including the Cursor in the array. it is a
reference type so you should have a local/valid handle to it in the
worker thread.

hope this helps
tim

"Tim_Mac" <mackey.tim@gmail.com> wrote in message
news:1139572494.494170.255830@g43g2000cwa.googlegroups.com...
| if we're talking .net 2.0, i would use the BackgroundWorker class and
| pass in the cursor as the argument. if you are already using the
| argument parameter, then send in an object array as the argument to the
| RunWorkerAsync method, including the Cursor in the array. it is a
| reference type so you should have a local/valid handle to it in the
| worker thread.
|
| hope this helps
| tim
|

I think you misunderstood or maybe I wasn't clear enough. I'm just replying
to yours :
<
....this has never happened to me just by reading a property of a control
that was created on another thread.
>
While it's perfectly valid to "read UI properties" in Windows, V2.0 of the
framework flags all UI accesses from non UI threads as illegal, which is not
true of course.

Willy.