Re: Making threadsafe calls : C# 2005

You just need to marshal it back to the UI thread via Control.Invoke or
Control.BeginInvoke.  The sample just encapsulates that in a single method
that first checks Control.InvokeRequired so that any thread can call the
method.

For example, on a non UI thread it's illegal to call TextBox.Text and to
marshal it back to the UI thread a delegate must be created for
Control.Invoke.

In .NET 2.0, this can be done without explictly creating the delegate and
anonymous delegates can be used:
  public void SetText(string text)
  {
   if (InvokeRequired)
   {
    this.Invoke((MethodInvoker)delegate
    {
     textBox1.Text =3D text;
    });
   }
   else
   {
    textBox1.Text =3D text;
   }

  }


This way you don't have to create a delegate like SetTextCallback
On Tue, 19 Jun 2007 21:20:48 -0400, Peter Osucha <[email protected]>
wrote:

>Thank you, Peter.
>
>So it seems that what I should be doing when my 'other thread' object
raises
>an event that is handled by one of my forms is to kick off a new thread
and
>have that thread update the necessary form controls.  Is this right?
>
>Peter
>
>-----Original Message-----
>From: Discussion relating to the specifics of the C# and Managed C++
>languages [mailto:[email protected]] On Behalf Of Peter
Ritchie
>Sent: Tuesday, June 19, 2007 7:28 PM
>To: [email protected]
>Subject: Re: [DOTNET-CX] Making threadsafe calls : C# 2005
>
>On Tue, 19 Jun 2007 14:49:38 -0400, Peter Osucha
><[email protected]> wrote:
>
>>(Eddie, your suggestion is what I am doing though for some reason, it
>>seems like 'cheating').
>
>It's not cheating, it's paving the way for making your life (or the person
>supporting customers) more difficult.
>
>Windows itself does not support cross-thread calls on most messages.
>(there was some chatter than this would change in Vista, but as far as I
>know it hasn't)  In most cases what happens is the thread receiving the
>message receives a pointer to memory that was sent on the other thread;
>because the other thread has continued running it may have deallocated
that
>memory by the  time the other thread accesses.  Under heavy load the
memory
>may have been reused by the time the other thread does anything with the
>memory--resulting in the destination thread getting completely different
>data (or even worse, data it doesn't have access to).  This manifests
itself
>as strange and random errors that are extremely difficult to track down.
>
>Yes, you can use things like setting CheckForIllegalCrossThreadCalls to
>false; but it's an indication of a big problem that if you put off by
>ignoring it, means a much more work when you do the eventual redesign.
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>This list is hosted by DevelopMentor=AE  http://www.develop.com
>
>View archives and manage your subscription(s) at
http://discuss.develop.com

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This list is hosted by DevelopMentor=AE  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com