When thread routine returns, that means it was closed ?

[Boki]

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_CallbackFunction()
{

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

}
}
....


}
/* CODE END */
Best regards,
Boki.

 

[Boki]

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_CallbackFunction()
{

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

}
}
...

}

/* 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.Image = new System.Drawing.Bitmap(new
System.IO.MemoryStream(new
System.Net.WebClient().DownloadData(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.

 

[Marc Gravell]

How about:

pictureBox1.LoadAsync(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.QueueUserWorkItem(delegate {
// runs on background thread
using(WebClient webClient = new WebClient())
using(MemoryStream stream = new
MemoryStream(webClient.DownloadData(url))) {
this.Invoke((MethodInvoker)delegate { // not
BeginInvoke, else stream might Dispose()
// runs on UI thread when data is available
pictureBox1.Image = 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

 

[Peter Duniho]

[...]
this.Invoke((MethodInvoker)delegate { // not
BeginInvoke, else stream might Dispose()
// runs on UI thread when data is available
pictureBox1.Image = 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

 

[Marc Gravell]

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.BeginInvoke((MethodInvoker) delegate {
// runs on UI thread when data is available
pictureBox1.Image = bmp;
}

Marc

 

[Peter Duniho]

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

Or (just to be complete):

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



Pete