Re: Backgroundworker Thread Issue
-
I have a winform where I dropped Backgroundworker control and running some loop in DoWork event handle. At the same time I am also within DoWork, I am calling "ReportProgress" method to update my ProgressBar. I thought as my work is going on within DoWork, I can click on other areas of Form and basically since its BackgroundWorker, my other GUI should be responsive but my whole Machine is frozen till "DoWork" finishes. What I am doing wrong? Here is code from :
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
//Do Intensive Work
ArgumentClass backGroundCls = e.Argument as ArgumentClass;//Now you can do whatever you want to do with passed arguments int ctr=0; do { ctr++; backgroundWorker1.ReportProgress(ctr); } while (ctr < 10000000);
Favourite quote: In youth we learn, In age we understand.
-
I have a winform where I dropped Backgroundworker control and running some loop in DoWork event handle. At the same time I am also within DoWork, I am calling "ReportProgress" method to update my ProgressBar. I thought as my work is going on within DoWork, I can click on other areas of Form and basically since its BackgroundWorker, my other GUI should be responsive but my whole Machine is frozen till "DoWork" finishes. What I am doing wrong? Here is code from :
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
//Do Intensive Work
ArgumentClass backGroundCls = e.Argument as ArgumentClass;//Now you can do whatever you want to do with passed arguments int ctr=0; do { ctr++; backgroundWorker1.ReportProgress(ctr); } while (ctr < 10000000);
Favourite quote: In youth we learn, In age we understand.
You may have separated the actual work into the background thread (Though I don't see this doing anything but incrementing a counter), but your ReportProgress calls themselves can lock up the GUI. Each time you ReportProgress, you're sending a message from the background thread to the GUI thread, which locks up the GUI thread for a tiny fraction of a second. If you're CONSTANTLY doing that, you'll find the GUI becomes locked up entirely. Try to reduce the frequency with which you send status updates... Maybe only send an update every X iterations, and do some testing to figure out a good value for X. And I assume you're planning on having the background worker do more than count, because that's really going to slow things down :)
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
I have a winform where I dropped Backgroundworker control and running some loop in DoWork event handle. At the same time I am also within DoWork, I am calling "ReportProgress" method to update my ProgressBar. I thought as my work is going on within DoWork, I can click on other areas of Form and basically since its BackgroundWorker, my other GUI should be responsive but my whole Machine is frozen till "DoWork" finishes. What I am doing wrong? Here is code from :
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
//Do Intensive Work
ArgumentClass backGroundCls = e.Argument as ArgumentClass;//Now you can do whatever you want to do with passed arguments int ctr=0; do { ctr++; backgroundWorker1.ReportProgress(ctr); } while (ctr < 10000000);
Favourite quote: In youth we learn, In age we understand.
As Ian has said above, you are updating your progress too often. Progress is normally a percentage, so between 0 and 100. You are counting to 10million so you probably only need to report every 10000 iterations. Also, if there is nothing else happening, the UI probably won't have time to update fully even then - if it hasn't got time to update then your users certainly won't have time to see it so the update is pointless!
Dave
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum. Astonish us. Be exceptional. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
I have a winform where I dropped Backgroundworker control and running some loop in DoWork event handle. At the same time I am also within DoWork, I am calling "ReportProgress" method to update my ProgressBar. I thought as my work is going on within DoWork, I can click on other areas of Form and basically since its BackgroundWorker, my other GUI should be responsive but my whole Machine is frozen till "DoWork" finishes. What I am doing wrong? Here is code from :
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
//Do Intensive Work
ArgumentClass backGroundCls = e.Argument as ArgumentClass;//Now you can do whatever you want to do with passed arguments int ctr=0; do { ctr++; backgroundWorker1.ReportProgress(ctr); } while (ctr < 10000000);
Favourite quote: In youth we learn, In age we understand.
The problem is you're reporting progress every loop iteration, essentially stalling both threads. You could reduce this greatly by doing the following:
ArgumentClass backGroundCls = e.Argument as ArgumentClass; int ctr=0; do { ctr++; if (ctr % 10000 == 0) backgroundWorker1.ReportProgress(ctr); } while (ctr < 10000000);
“I have no special talents. I am only passionately curious.” - Albert Einstein
-
I have a winform where I dropped Backgroundworker control and running some loop in DoWork event handle. At the same time I am also within DoWork, I am calling "ReportProgress" method to update my ProgressBar. I thought as my work is going on within DoWork, I can click on other areas of Form and basically since its BackgroundWorker, my other GUI should be responsive but my whole Machine is frozen till "DoWork" finishes. What I am doing wrong? Here is code from :
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
//Do Intensive Work
ArgumentClass backGroundCls = e.Argument as ArgumentClass;//Now you can do whatever you want to do with passed arguments int ctr=0; do { ctr++; backgroundWorker1.ReportProgress(ctr); } while (ctr < 10000000);
Favourite quote: In youth we learn, In age we understand.
Even when using the Background worker, I advice to make use of BeginInvoke methods to update the user interface elements. This has worked for me big time. Create appropriate delegates for user interface updates and invoke them as and when necessary.
Sunil
-
Even when using the Background worker, I advice to make use of BeginInvoke methods to update the user interface elements. This has worked for me big time. Create appropriate delegates for user interface updates and invoke them as and when necessary.
Sunil
-
The problem is you're reporting progress every loop iteration, essentially stalling both threads. You could reduce this greatly by doing the following:
ArgumentClass backGroundCls = e.Argument as ArgumentClass; int ctr=0; do { ctr++; if (ctr % 10000 == 0) backgroundWorker1.ReportProgress(ctr); } while (ctr < 10000000);
“I have no special talents. I am only passionately curious.” - Albert Einstein
-
Sunil, In what way it has helped you more? Can you share your thoughts more please?
Favourite quote: In youth we learn, In age we understand.
Hey munishk, I had developed and application that created approximate of 20 Background workers. All these workers had to update progressbars embedded in a listview for around 20 listview items. However, initially the DoWork event handler used to update the UI which made the UI very sloppy and was sometimes showing a hung behavior. I changed the implementation to make use of Delegates to update the UI and by calling the BeginInvoke method this issue got resolved.
// declare a delegate to update your progress
void delegate UpdateProgressDelegate(object params);private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
//Do Intensive Work
ArgumentClass backGroundCls = e.Argument as ArgumentClass;//Now you can do whatever you want to do with passed arguments int ctr=0; do { ctr++; UpdateProgressDelegate del = new UpdateProgressDelegate(UpdateProgress); del.BeginInvoke(ctr, null, null); } while (ctr < 10000000);
}
private void UpdateProgress(int ctr)
{
// update progress here
}This should definitely work and solve your issue.
Sunil