Re: Monitoring Threads

If you're sure you'll have a message pump running, then using the
System.Windows.Forms timer will ensure the Elapsed event (if that's what
event is fired for that timer -- can't recall) fires on the UI thread.
And you could always check the Application.MessageLoop property before
doing anything and throw some kind of exception to let consumers of your
component know that they must call your component from a UI thread.

--
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: Thursday, March 29, 2007 7:54 AM
To: [email protected]
Subject: Re: [DOTNET-WINFORMS] Monitoring Threads


I think I can safely assume that my dll will always be used in a GUI
environment.  Does that automatically free me to use the
System.Forms.Timer? Do I need to do anything in the dll differently when
I use the System.Forms.Timer?

And thanks for your help.  This is VERY helpful.  My last day at this
job is tomorrow, and I wanted this dll to be done.  With this info, that
might just happen.

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:[email protected]] On Behalf Of
Patrick Steele
Sent: Thursday, March 29, 2007 6:45 AM
To: [email protected]
Subject: Re: [DOTNET-WINFORMS] Monitoring Threads

The System.Windows.Forms.Timer requires a message pump -- it's designed
to be used in a single-threaded GUI environment.  In your original
message, you're creating your own threads and then running
BackgroundWorkers on those threads.  And you're creating a generic
component that can be used in both a GUI and non-GUI environment?  If
that is correct, you can't assume a windows message pump is running and
should avoid System.Windows.Forms.Timer.

At this point I believe your options are:

1) Document that your component raises events on background threads and
that any UI routines should check the InvokeRequired property.

2) Rework your component a bit so that the BackgroundWorkers are
launched off the same thread that called into the component (assuming
this is the UI thread).  That way the completed event will also run in
the UI thread.

I'm sure there's some more options -- it depends on how much work you
want to do and how "generic" you want this component.

Hope that helps!

--
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: Thursday, March 29, 2007 7:30 AM
To: [email protected]
Subject: Re: [DOTNET-WINFORMS] Monitoring Threads


Thanks for this info.  How do I get around this in the dll?  Peter
Ritchie said to use a System.Forms.Timer.  Can I use that in a dll that
does not have a GUI?

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:[email protected]] On Behalf Of
Patrick Steele
Sent: Wednesday, March 28, 2007 10:05 PM
To: [email protected]
Subject: Re: [DOTNET-WINFORMS] Monitoring Threads

The System.Timers.Timer Elapsed event is run on a ThreadPool thread.  So
yes, if you start a BackgroundWorker in the Elapsed event, your running
on thread different than the main UI thread.

--
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: Wednesday, March 28, 2007 10:09 PM
To: [email protected]
Subject: Re: [DOTNET-WINFORMS] Monitoring Threads


I'm trying NOT to call RunWorkerAsync from a background thread.  I am
running it in a System.Timers.Timer elapsed event.  Does the Timer
automatically run in a different thread?  That's what I wanted to find
out by monitoring what thread running what routines.  Is there a call
that will give me the thread ID as shown in the Thread window of the
debugger?

Thanks,
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: Wednesday, March 28, 2007 8:28 PM
To: [email protected]
Subject: Re: [DOTNET-WINFORMS] Monitoring Threads

The completed and progress events are called on the same thread that
calls the RunWorkerAsync method.  If you call the RunWorkerAsync method
on a thread other than the GUI thread then you'll get cross-threading
exceptions when you try to access Control data from within those event
handlers.

Why are you calling RunWorkerAsync from a background thread?  I.e. what
are you trying to accomplish?  There's several ways to approach this,
I'm just trying to find out what way would be best.


On Wed, 28 Mar 2007 19:37:08 -0500, Kelly Baker
<[email protected]> wrote:

>I am still working on that dll that runs a process in a different
>thread, then raises a NewData event for the calling executable.  I have

>redone it using the BackgroundWorker class to do my threading.  I have
>a System.Timers.Timer object that runs the RunWorkerAsync method.  In
>the RunWorkerCompleted event I raise the NewData event.  But the
>executable still raises the cross-threading error when I try to update
>the form controls.  Is there a way to programmatically get the thread
>ID that is displayed on the Threads debug window?  I would like to log
>what thread is active with each operation until I can find where my
>problem is.