Re: Updating controls on a form

Thanks!  I was under the assumption that the BackgroundWorker class was only
used in code with a Windows form.  I had not thought to check otherwise.  I
will rewrite the dll tomorrow using the BackgroundWorker class.

Kelly

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:[email protected]] On Behalf Of Peter
Ritchie
Sent: Sunday, March 25, 2007 6:42 PM
To: [email protected]
Subject: Re: [DOTNET-WINFORMS] Updating controls on a form

It can get a little hairy trying to marshal to an applicable thread.  The
easiest way is to use the BackgroundWorker class.  The DoWork event
handler will be called with a thread pool thread but the Progress and
Completed event handlers will be called on the same thread that called
RunWorkerAsync.  So, if your DLL is called from an application's GUI
thread and you call RunWorkerAsync you can simply raise an event back to
the app either during the Progress or Complete events...

If you don't want to use the BackgroundWorker class you'll have to do that
InvokeRequired/BeginInvoke dance; which means you need a Control reference
from somewhere.

You can do essentially the same thing as the BackgroundWorker class by
using the AsyncOperationManager class [1]; but it can quickly become very
complex.

[1] http://msdn2.microsoft.com/en-
us/library/system.componentmodel.asyncoperationmanager.aspx

On Sun, 25 Mar 2007 18:18:11 -0500, Kelly Baker
<[email protected]> wrote:

>There is no form in my dll.  The Windows form is in the calling
executable.
>I do want the timer and the code that it runs in a separate thread.  I was
>just wondering how I could have it doing the grunt work in a separate
>thread, but have shared variables that the properties return, without the
>calling executable having to go through all of this.
>
>Thanks,
>Kelly
>
>-----Original Message-----
>From: Discussion forum for developers using Windows Forms to build apps
and
>controls [mailto:[email protected]] On Behalf Of Patrick
>Steele
>Sent: Sunday, March 25, 2007 7:28 AM
>To: [email protected]
>Subject: Re: [DOTNET-WINFORMS] Updating controls on a form
>
>You should be using the System.Windows.Forms.Timer instead.  From the
>documentation on System.Threading.Timer:
>
>"System.Threading.Timer is a simple, lightweight timer that uses
>callback methods and is served by thread pool threads. It is not
>recommended for use with Windows Forms, because its callbacks do not
>occur on the user interface thread. System.Windows.Forms.Timer is a
>better choice for use with Windows Forms."
>
>--
>Patrick Steele
>http://weblogs.asp.net/psteele
>
>
>
>-----Original Message-----
>From: Discussion forum for developers using Windows Forms to build apps
>and controls [mailto:[email protected]] On Behalf Of
>Kelly Baker
>Sent: Saturday, March 24, 2007 10:37 PM
>To: [email protected]
>Subject: [DOTNET-WINFORMS] Updating controls on a form
>
>
>Unless my app is EXTREMELY simple, I get the cross-threading error
>message regularly when updating controls on a Windows form.
>
>My latest example involves a dll that runs a System.Threading.Timer,
>updating private shared variables.  When it finishes updating, it raises
>a NewData event.  My app responds to that event by updating display
>controls (labels in this case).  I have to use a delegate and update
>them like this:
>
>Private Sub SetText(ByVal [text] as String)
>    If Me.Messages.InvokeRequired Then
>        Dim d as New SetTextCallBack(AddressOf SetText)
>        Me.Invoke(d, New Object() {[text]})
>    Else
>        Me.Messages.Text = [text]
>    End If
>End Sub
>
>I have to write a different routine like this for each control on the
>form that I want to update.  Is there a better way?  Please?