BackgroundWorke r and 'freezing' application

[Sebastian Crewe]

Greetings,

I was much encouraged to see the new BackgroundWorke r class in .NET v2. On
the face of it, much easier to use than the various delegates and events of
yore, though I imagine the same base classes are being invoked.

Anyway, I have given it a try with a VB.NET application that generates
charts. Since there are some 3,000 charts to do, I wanted to put the chart
generation on a separate thread. Works fine inasmuch as the charts are made.
The problem is that the form UI is frozen after the job completes.
Actually, I think it freezes at some point during the background job running
but I haven't been able to determine if it is always after a fixed amount of
time.

For the first few minutes of background thread operation, I can move the
form around, minimize it etc. I repeat this exercise from time to time; most
often, the form is still responsive while othertimes it freezes. I am
testing this on a dual CPU HP DC7100, XP Pro, SP2.

I have treble-checked that nothing in the background thread touches the
form. I use a separate SQL connection from that used for populating UI
controls; I have taken the BackgroundWorke r1 object off the form design
surface and declared it manually (WithEvents); I have commented out all
ReportProgress calls (saw something on these perhaps being too frequent).

At the end of the job, I pop up a message box to say all done. This is
within the RunWorkerComple ted event. My understanding is that once this
event fires, then the background thread is finished and control is
automatically handed back to the UI thread. Is this correct?

Any ideas as to why the form freezes gratefully received. Are there any
tricks I can employ to determine at which point things are going wrong?

Thanks and regards

Sebastian Crewe

[Carlos J. Quintero [VB MVP]]

Take a look at the basics here (the BackgroundWorke r class is a helper class
added to .NET 2.0):

Resources about asynchronous operations
http://www.mztools.com/resources_net...nousOperations

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com
"Sebastian Crewe" <Se************ @discussions.mi crosoft.com> escribió en el
mensaje news:38******** *************** ***********@mic rosoft.com...

Greetings,

I was much encouraged to see the new BackgroundWorke r class in .NET v2.
On
the face of it, much easier to use than the various delegates and events
of
yore, though I imagine the same base classes are being invoked.

Anyway, I have given it a try with a VB.NET application that generates
charts. Since there are some 3,000 charts to do, I wanted to put the
chart
generation on a separate thread. Works fine inasmuch as the charts are
made.
The problem is that the form UI is frozen after the job completes.
Actually, I think it freezes at some point during the background job
running
but I haven't been able to determine if it is always after a fixed amount
of
time.

For the first few minutes of background thread operation, I can move the
form around, minimize it etc. I repeat this exercise from time to time;
most
often, the form is still responsive while othertimes it freezes. I am
testing this on a dual CPU HP DC7100, XP Pro, SP2.

I have treble-checked that nothing in the background thread touches the
form. I use a separate SQL connection from that used for populating UI
controls; I have taken the BackgroundWorke r1 object off the form design
surface and declared it manually (WithEvents); I have commented out all
ReportProgress calls (saw something on these perhaps being too frequent).

At the end of the job, I pop up a message box to say all done. This is
within the RunWorkerComple ted event. My understanding is that once this
event fires, then the background thread is finished and control is
automatically handed back to the UI thread. Is this correct?

Any ideas as to why the form freezes gratefully received. Are there any
tricks I can employ to determine at which point things are going wrong?

Thanks and regards

Sebastian Crewe

[Sebastian Crewe]

Thank you for the quick reply. I have been through these and similar
documentation. Most of the content is based on the underlying way of using a
background thread, not with using the BackgroundWorke r class.

I was hoping to avoid doing a rewrite, using delegates, BeginInvoke etc,
since that is what the BackgroundWorke r class is supposed to help with. The
problem remains of the user UI appearing to freeze; certainly it is
unresponsive, eg to being moved around. Meanwhile, Task Manager shows 0% CPU
for my application.

My background thread works fine if the job to complete takes 5 minutes or
less. I am not aware of a defualt timeout with background threads, but
perhaps I need to give wake up calls to the user UI once in a while? Any
guidelines for this? Is the fact that the PC has multi-processors something
I should be dealing with explicitly?

Thanks and regards

Sebastian

"Carlos J. Quintero [VB MVP]" wrote:

Take a look at the basics here (the BackgroundWorke r class is a helper class
added to .NET 2.0):

Resources about asynchronous operations
http://www.mztools.com/resources_net...nousOperations

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com
"Sebastian Crewe" <Se************ @discussions.mi crosoft.com> escribió en el
mensaje news:38******** *************** ***********@mic rosoft.com...

Greetings,

I was much encouraged to see the new BackgroundWorke r class in .NET v2.
On
the face of it, much easier to use than the various delegates and events
of
yore, though I imagine the same base classes are being invoked.

Anyway, I have given it a try with a VB.NET application that generates
charts. Since there are some 3,000 charts to do, I wanted to put the
chart
generation on a separate thread. Works fine inasmuch as the charts are
made.
The problem is that the form UI is frozen after the job completes.
Actually, I think it freezes at some point during the background job
running
but I haven't been able to determine if it is always after a fixed amount
of
time.

For the first few minutes of background thread operation, I can move the
form around, minimize it etc. I repeat this exercise from time to time;
most
often, the form is still responsive while othertimes it freezes. I am
testing this on a dual CPU HP DC7100, XP Pro, SP2.

I have treble-checked that nothing in the background thread touches the
form. I use a separate SQL connection from that used for populating UI
controls; I have taken the BackgroundWorke r1 object off the form design
surface and declared it manually (WithEvents); I have commented out all
ReportProgress calls (saw something on these perhaps being too frequent).

At the end of the job, I pop up a message box to say all done. This is
within the RunWorkerComple ted event. My understanding is that once this
event fires, then the background thread is finished and control is
automatically handed back to the UI thread. Is this correct?

Any ideas as to why the form freezes gratefully received. Are there any
tricks I can employ to determine at which point things are going wrong?

Thanks and regards

Sebastian Crewe