On Wed, 11 Jun 2008 17:07:00 -0700, Sujeet
<Su****@discuss ions.microsoft. comwrote:
Thread constructor has an overload that takes ParameterizedTh readStart
delegate as one of its parameter. You can use that to pass an object
from the
caller
The best way to return some value back to the caller is to set some
value on
the passed Object.
The "best way"? I disagree. In fact, that's likely to be the absolute
worst way, unless you combine with some sort of event-driven inter-thread
communication as well. Otherwise, the other thread can only detect the
completion by polling the value being set.
As far as the original question goes:
Based on the problem description so far, I think that the BackgroundWorke r
class is probably your best bet. Subscribe to the DoWork and
RunWorkerComple ted events, and the delegate method subscribed to each
event will be run on the correct thread: the DoWork handler will be run on
a background thread, and the RunWorkerComple ted handler will be run on the
original thread (the GUI thread in this case).
That is probably sufficient advice, but if you decide that for some reason
the BackgroundWorke r class isn't appropriate, here are some other details
(note that the BackgroundWorke r class is a special case of all of the
following, fully encapsulating the techniques described as part of the
basic functionality of the BackgroundWorke r class)...
The best way to deal with the "thread complete" scenario is to call a
method. If the code executing in the thread is part of the same class
that starts the thread (for example, a Form sub-class), then you can just
call some specific method within the class. Otherwise, it would probably
make more sense for the class containing the thread code to allow for the
calling class to provide a delegate to be called with the thread code
completes.
The usual way to do this latter approach is to declare an event on the
thread class, have the client subscribe to the event, and then raise the
event when the thread is done. An alternative would be, for example, to
simply allow the caller to pass a delegate directly, and then invoke the
delegate when the thread is done (this is basically what an event does
anyway, but in a more flexible, general-purpose way).
Now, to get the "completed" code to execute on a specific thread, you need
some way to marshal the execution onto that specific thread. Since you
are apparently trying to get back onto your main GUI thread, the most
appropriate mechanism for doing this would be to use the Control.Invoke( )
method. If the thread code is already fully "aware of" the GUI code (e.g.
it's actually part of the Form sub-class), then you might as well just
call Invoke() from within the thread code. Otherwise, it will probably
make more sense to have the thread call some specific method in the client
class (via the mechanisms described above), and let that method deal with
calling Invoke() on the appropriate instance.
As far as sample code goes, use Google or MSDN search to look for specific
topics on the use of BackgroundWorke r, Control.Invoke( ) and the C# "event"
keyword. There is no shortage of existing examples in MSDN, this
newsgroup, and a variety of other web sites.
Pete