Windows Forms - stop form looking like it has crashed whilst routine running

[Ben]

Hi

We have a windows form that takes a while to run a routine.

During this we have created a information label, updating the user on the
progress but:

a) The changes on the label are not visible until the routine has finished
b) If the form looses focus it appears to the user that it has crashed

Is there any way to stop the above from happening?

Thanks
B

[info]

Hi Ben,

the only way to keep your form responsive is to run the time consuming
code in a different thread. If you're using .NET Framework 2.0 and
Visual Studio 2005 you can use a new component called
"BackgroundWork er", which makes the handling of an additional thread
much easier. Please refer to the online help by searching for
BackgroundWorke r. One important hint: don't try to update any form
controls in the event handler for the DoWork-Event because winform
controls can only be updated by the thread that created them, use the
ProgressChanged-Event instead.

cya
Axel

Ben a écrit :

Hi

We have a windows form that takes a while to run a routine.

During this we have created a information label, updating the user on the
progress but:

a) The changes on the label are not visible until the routine has finished
b) If the form looses focus it appears to the user that it has crashed

Is there any way to stop the above from happening?

Thanks
B

[\(O\)enone]

Ben wrote:

Is there any way to stop the above from happening?

The "best" route is almost certainly to run the time-consuming routine in
another thread, as has already been suggested.

However an easier solution that may well still accomplish your goal is to
get the window to repaint itself from time to time.

At regular intervals within your code you can either force the form to
refresh itself:

\\\
Me.Refresh()
///

(assuming the code is running within a procedure within the form itself) or
alternatively allow the application to process all queued events:

\\\
Application.DoE vents()
///

The Refresh method will cause all visual elements of the form to be updated.
This will get your label text update fixed and will get the window to
repaint if other windows have obscured it. You won't be able to interact
with the window however until the routine has finished, as the events will
be queued but temporarily ignored. Once the procedure is finished, all the
queued events will be processed together.

The DoEvents method will allow the screen to repaint and the label to be
updated, and will also process any events that have been queued. This will
allow the user to, for example, move or close the window, click buttons and
interact with other UI elements.

Have a go with these and see if they do what you want.

--

(O)enone

[Ben]

Thank you both for your posts. I will use Refresh Now and will consider
multithreading in the future.

Thanks
B
"(O)enone" <oe****@nowhere .comwrote in message
news:Gn******** **********@news fe5-win.ntli.net...

Ben wrote:

>Is there any way to stop the above from happening?

The "best" route is almost certainly to run the time-consuming routine in
another thread, as has already been suggested.

However an easier solution that may well still accomplish your goal is to
get the window to repaint itself from time to time.

At regular intervals within your code you can either force the form to
refresh itself:

\\\
Me.Refresh()
///

(assuming the code is running within a procedure within the form itself)
or alternatively allow the application to process all queued events:

\\\
Application.DoE vents()
///

The Refresh method will cause all visual elements of the form to be
updated. This will get your label text update fixed and will get the
window to repaint if other windows have obscured it. You won't be able to
interact with the window however until the routine has finished, as the
events will be queued but temporarily ignored. Once the procedure is
finished, all the queued events will be processed together.

The DoEvents method will allow the screen to repaint and the label to be
updated, and will also process any events that have been queued. This will
allow the user to, for example, move or close the window, click buttons
and interact with other UI elements.

Have a go with these and see if they do what you want.

--

(O)enone