Re: Making threadsafe calls : C# 2005

Ahh, after re-reading yours and Adam's message, I think I finally
understand what is going on here. =20

In the form that is responding to events raised by my non-UI object (in
the event handler I have already set up on the form to handle each
event), I am checking to see if InvokeRequired is true.  If it is, I am
essentially calling a different instance of the same event handler (the
one I am creating) which has been created on a thread the UI elements
can access and then returning before actually doing any updating of form
elements.  When the new instance of the event handler is 'Invoked', then
InvokeRequired will be false and so the methods that do the updating
will be called.  Correct?

Peter

Here is the code I am using in this 'DataReceived' event...

private void _instrument_DataReceived ( object sender,
DataReceivedEventArgs e )
{
    if ( this.InvokeRequired )
    { this.Invoke (new
Instrument.DataReceivedEventHandler(_instrument_DataReceived),sender,e);
        return;
    }

    // This stuff (which updates form controls) is never reached unless
'InvokeRequired' is false above.
    // which means we are operating on a 'local' thread.
    UpdateGridData ( );

    UpdateGraphData ( );

    UpdateWellData ( );

    UpdateStatusBarStatus ( );

}

-----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 11:25 PM
To: [email protected]
Subject: Re: [DOTNET-CX] 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