When thread routine returns, that means it was closed ?

On Jul 9, 2:35 pm, Boki <bokit...@ms21. hinet.netwrote:

Hi All,

When thread returns, that means the thread is closed ?
What is the standard way to kill it ?

threadA= null ;

Thank you for advice!
/* CODE BEGIN */

public partial class Form1 : Form
{
private static Thread thread_Interent ;
...

public void Boki_internet_C allbackFunction ()
{

{
// code a b c d e g g
Thread.Sleep(10 00);

}
}
...

}

/* CODE END */
Best regards,
Boki.

My issue is, my form is running, user needs to type some text in a
textbox, and the thread is downloading data from internet by this
line:

pictureBox1.Ima ge = new System.Drawing. Bitmap(new
System.IO.Memor yStream(new
System.Net.WebC lient().Downloa dData(picStr))) ;

if there is no thread, program will be completely block until the
picture was loaded.

so, I only need this thread starting work when I need it to load a
picture.

Could you please advice any idea ?

Thanks a lot!

Best regards,
Boki.

How about:

pictureBox1.Loa dAsync(url);

The best way of stopping a thread is to let it exit cleanly, possibly
getting it to short-circuit internally by toggling a flag or whatver
(to break from a loop). Setting a varible (to the thread) to null
doesn't impact the thread in the least.

In the more general sense, when working with forms you can use
pool-threads to perform background activities, e.g.

void StartLoadImage( string url) {
// runs on UI thread when method invoked
ThreadPool.Queu eUserWorkItem(d elegate {
// runs on background thread
using(WebClient webClient = new WebClient())
using(MemoryStr eam stream = new
MemoryStream(we bClient.Downloa dData(url))) {
this.Invoke((Me thodInvoker)del egate { // not
BeginInvoke, else stream might Dispose()
// runs on UI thread when data is available
pictureBox1.Ima ge = new Bitmap(stream);
});
}
});
}

You can also use async-callbacks, but I find the above easier to
read... but it doesn't take advantage of completion ports, etc...

Marc

On Mon, 09 Jul 2007 00:21:22 -0700, Marc Gravell <ma**********@g mail.com
wrote:

[...]
this.Invoke((Me thodInvoker)del egate { // not
BeginInvoke, else stream might Dispose()
// runs on UI thread when data is available
pictureBox1.Ima ge = new Bitmap(stream);
});

Maybe I'm missing something, but why not just create the Bitmap from the
Stream in the background delegate, instead of passing the Stream to the UI
delegate to be used to construct the Bitmap? Then you're not tied to
Invoke() versus BeginInvoke().

Pete

why not just create the Bitmap from the Stream in the background delegate

Looking at it again, I can't think of any reason not to... I guess it
didn't occur to me at the time (it was a hasty example, to show the
general case, given that LoadAsync exists).

For the OP's benefit, this would look like:

....
Bitmap bmp = new Bitmap(stream);
this.BeginInvok e((MethodInvoke r) delegate {
// runs on UI thread when data is available
pictureBox1.Ima ge = bmp;
}

Marc

On Mon, 09 Jul 2007 21:00:20 -0700, Marc Gravell <ma**********@g mail.com
wrote:

For the OP's benefit, this would look like:

Or (just to be complete):

....
Bitmap bmp = new Bitmap(stream);
this.Invoke((Me thodInvoker) delegate {
// runs on UI thread when data is available
pictureBox1.Ima ge = bmp;
}

:)

Pete