worker thread shutdown and Form.Invoke

I have a background worker thread which I start from a form's HandleCreated
event that makes calls back to the form using Invoke. During shutdown the
form is disposed and the background worker thread is aborted by the system.

How is one to keep the background thread from calling form.Invoke after the
form's window handle has been destroyed?

I have a background worker thread which I start from a form's HandleCreated
event that makes calls back to the form using Invoke. During shutdown the
form is disposed and the background worker thread is aborted by the
system.

How is one to keep the background thread from calling form.Invoke after
the
form's window handle has been destroyed? This is definitely happening in
my
application. I haven't read anything about this problem in old postings
or
on the web. If this shouldn't happen and I'm doing something out of the
ordinary to cause this, could someone please explain why it doesn't happen
in the normal case. Thanks in advance.
If this helps, the worker thread is reading data from a TCPClient object
using the blocking Read method. The worker thread may also execute unsafe
code to process the data from the TCPClient object. Updating the UI with
information read off the TCPClient object is the worker threads only job.
So, it can abort as soon as the form goes away. The main UI thread is not
the thread which spawned the application but it is the one and only
non-background thread. The main UI thread is created before the worker
thread.

If no one has seen or heard of this problem, I'll try to write a minimal
demonstration of the problem and post the code.

Thanks,
Steve

I have a background worker thread which I start from a form's HandleCreated event that makes calls back to the form using Invoke. During shutdown the
form is disposed and the background worker thread is aborted by the system.
How is one to keep the background thread from calling form.Invoke after the form's window handle has been destroyed? This is definitely happening in my application. I haven't read anything about this problem in old postings or on the web. If this shouldn't happen and I'm doing something out of the
ordinary to cause this, could someone please explain why it doesn't happen
in the normal case. Thanks in advance.
If this helps, the worker thread is reading data from a TCPClient object
using the blocking Read method. The worker thread may also execute unsafe
code to process the data from the TCPClient object. Updating the UI with
information read off the TCPClient object is the worker threads only job.
So, it can abort as soon as the form goes away. The main UI thread is not
the thread which spawned the application but it is the one and only
non-background thread. The main UI thread is created before the worker
thread.

If no one has seen or heard of this problem, I'll try to write a minimal
demonstration of the problem and post the code.

Thanks,
Steve

Make sure you close the thread down before closing the form (i.e. in the
Closing event, etc.), and the Worker.Stop() method should handle socket
shutdown, etc. You should not leave closing event method until the
thread(s) are stopped.

"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Make sure you close the thread down before closing the form (i.e. in the
Closing event, etc.), and the Worker.Stop() method should handle socket
shutdown, etc. You should not leave closing event method until the
thread(s) are stopped.
Your solution seems simple but when I think of implementing it, I always

get either a race condition or deadlock.

My worker thread calls back to the UI thread when errors occur, if this
makes a difference. If this is not the right way to do it, could you point me that way?

Any chance you could flesh out the detail of your solution?

Thanks much for the input.