DoEvents() "Hangs"

[cedmunds]

Group:

We have an application that is calling a stored proc. The stored proc
takes anywhere from 15 to 90 minutes to run.

In order to keep the GUI responsive, we are using a BackgroundWorke r to
actually make the call to the stored proc. The app then sits in a loop
that awakes every second and updates an elapsed time value.

The problem that we are having is that after a certain period of time -
which is rarely the same amount - the call to DoEvents hangs (does not
return).

I was hoping the group could help us with: a) why thiat might be
occuring and b) what if anything can be done to fix it.

Here's the key areas of the code:

This is from the method that starts the ball rolling:

[Shawn Wildermuth (C# MVP)]

Hello ce******@ocv.co m,

Do people really still use DoEvents() (is it even valid in C#?). You should
be using Thread.Join or Thread.Sleep (or a synchronization semantic like
a Mutex or Monitor).
Thanks,
Shawn Wildermuth
Speaker, Author and C# MVP
http://adoguy.com

Group:

We have an application that is calling a stored proc. The stored proc
takes anywhere from 15 to 90 minutes to run.

In order to keep the GUI responsive, we are using a BackgroundWorke r
to actually make the call to the stored proc. The app then sits in a
loop that awakes every second and updates an elapsed time value.

The problem that we are having is that after a certain period of time
- which is rarely the same amount - the call to DoEvents hangs (does
not return).

I was hoping the group could help us with: a) why thiat might be
occuring and b) what if anything can be done to fix it.

Here's the key areas of the code:

This is from the method that starts the ball rolling:
.
.
.
case "Consolidat e Revenue": {
bgwThread.RunWo rkerAsync( cConsolidateRev enue );
SleepAndUpdate( );
break;
}
.
.
.
This is from the "DoWork" event handler:

private void bgwThread_DoWor k( object sender, DoWorkEventArgs e )
{
switch ((int)e.Argumen t) {
case cConsolidateRev enue: {
ConsolidateReve nue( cn, dtPickerStartDa te.Value.Date,
dateImportEndDa te );
break;
}
.
.
.
Here is SleepAndUpdate:
private void SleepAndUpdate( ) {
while (notDone) {
ShowElapsedTime ();
Application.DoE vents();
System.Threadin g.Thread.Sleep( 1000 );
}
}
We have verfied that the app is indeed haning on the call to
DoEvents()

Thank you for your help

[Greg Young]

Why are you having the front end stop if you are running the operation on a
background thread anyways?

Couldn't you just make the background thread tell the front end when it is
done through a callback/event/etc

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

<ce******@ocv.c omwrote in message
news:11******** **************@ 75g2000cwc.goog legroups.com...

Group:

We have an application that is calling a stored proc. The stored proc
takes anywhere from 15 to 90 minutes to run.

In order to keep the GUI responsive, we are using a BackgroundWorke r to
actually make the call to the stored proc. The app then sits in a loop
that awakes every second and updates an elapsed time value.

The problem that we are having is that after a certain period of time -
which is rarely the same amount - the call to DoEvents hangs (does not
return).

I was hoping the group could help us with: a) why thiat might be
occuring and b) what if anything can be done to fix it.

Here's the key areas of the code:

This is from the method that starts the ball rolling:
.
.
.
case "Consolidat e Revenue": {
bgwThread.RunWo rkerAsync( cConsolidateRev enue );
SleepAndUpdate( );
break;
}
.
.
.

This is from the "DoWork" event handler:

private void bgwThread_DoWor k( object sender, DoWorkEventArgs e ) {
switch ((int)e.Argumen t) {
case cConsolidateRev enue: {
ConsolidateReve nue( cn, dtPickerStartDa te.Value.Date,
dateImportEndDa te );
break;
}
.
.
.

Here is SleepAndUpdate:
private void SleepAndUpdate( ) {
while (notDone) {
ShowElapsedTime ();
Application.DoE vents();
System.Threadin g.Thread.Sleep( 1000 );
}
}
We have verfied that the app is indeed haning on the call to DoEvents()

Thank you for your help

[cedmunds]

The business requirements are such that the call needs to be
synchronous but the GUI needs to be semi-responsive while it is
running.

The users are not able to perform any other taks in the app while the
call is being processed but when the process is long running they
don't want the screen to "white" out either.

That is the only reason for the threading.

[wfairl]

Then you need to just disable the GUI programmiticall y. Thread.Sleep()
on the UI thread is never correct. Look into using the BackgroundWorke r
class for a simple and sound solution if you're using 2.0.

http://msdn2.microsoft.com/en-us/lib...undworker.aspx

ce******@ocv.co m wrote:

The business requirements are such that the call needs to be
synchronous but the GUI needs to be semi-responsive while it is
running.

The users are not able to perform any other taks in the app while the
call is being processed but when the process is long running they
don't want the screen to "white" out either.

That is the only reason for the threading.

[cedmunds]

Exactly, I am using the BackgroundWorke r (see code snippets) above. In
essence, I am firing off the stored proc and then putting the GUI in a
loop that sleeps for a while, awakens, and updates itself and then goes
back to sleep. This continues until the stored proc returns.

But the trouble is that it (the SleepAndUpdate loop) stops working
after a while. When it first fires up, everything is great and then
after an indeterminate period of time the DoEvents() stops returning.

It is puzzling.

I hate to take the "easy" way out and point to the framework but that
is indeed what it seems like the trouble is.

All helpful thoughts and suggestions (not the snarky ones about "Do
people really still use DoEvents() (is it even valid in C#?).") are
appreciated.

wf****@gmail.co m wrote:

Then you need to just disable the GUI programmiticall y. Thread.Sleep()
on the UI thread is never correct. Look into using the BackgroundWorke r
class for a simple and sound solution if you're using 2.0.

http://msdn2.microsoft.com/en-us/lib...undworker.aspx

[wfairl]

Don't sleep on the UI thread. Ever. You're preventing the UI
thread from processing any messages for 1 second. Disable the main form
and its controls or launch another simple modal form to actually launch
the processing thread and display some sort of "I'm running" indicator
until it receives notification (not by polling, by callback) that the
thread has finished.
Your implementation is broken, not the framework. This is not meant
to be snarky, just straightforward .

ce******@ocv.co m wrote:

Exactly, I am using the BackgroundWorke r (see code snippets) above. In
essence, I am firing off the stored proc and then putting the GUI in a
loop that sleeps for a while, awakens, and updates itself and then goes
back to sleep. This continues until the stored proc returns.

But the trouble is that it (the SleepAndUpdate loop) stops working
after a while. When it first fires up, everything is great and then
after an indeterminate period of time the DoEvents() stops returning.

It is puzzling.

I hate to take the "easy" way out and point to the framework but that
is indeed what it seems like the trouble is.

All helpful thoughts and suggestions (not the snarky ones about "Do
people really still use DoEvents() (is it even valid in C#?).") are
appreciated.

wf****@gmail.co m wrote:

Then you need to just disable the GUI programmiticall y. Thread.Sleep()
on the UI thread is never correct. Look into using the BackgroundWorke r
class for a simple and sound solution if you're using 2.0.

http://msdn2.microsoft.com/en-us/lib...undworker.aspx

[cedmunds]

wfa:

Sorry, I wasn't indicting you. I just get frustrated with condescending
posts.

In any case, the issue is that when the call returns then we must move
onto the next step in the process. We let the stored proc run in the
back ground BUT we can't continue on with processing until the stored
proc returns. That is why we go into a sleep loop. Otherwise, we just
loop until the semaphore is reset.

[e-mail] m wrote:

Don't sleep on the UI thread. Ever. You're preventing the UI
thread from processing any messages for 1 second. Disable the main form
and its controls or launch another simple modal form to actually launch
the processing thread and display some sort of "I'm running" indicator
until it receives notification (not by polling, by callback) that the
thread has finished.
Your implementation is broken, not the framework. This is not meant
to be snarky, just straightforward .

[Greg Young]

I agree with this completely.

You can just leave the UI doing nothing and wait on an event from the worker
thread (i.e. with a modal dialog). This is a quite common task (and many
people include "cancel" buttons on such a screen so the user can stop what
they are doing).

Personally I would also question the business requirement of having a user
on the system unable to use their interface for 15-90 minutes as this sounds
exactly like the type of job that should be done by some system service. By
putting the requirement that the person can't do anything when this is
happenning also leads directly to the conclusion that noone can be doing
anything while this happens on the database (or atleast touching the same
data).

Cheers,

Greg

<wf****@gmail.c omwrote in message
news:11******** **************@ i42g2000cwa.goo glegroups.com.. .

Don't sleep on the UI thread. Ever. You're preventing the UI
thread from processing any messages for 1 second. Disable the main form
and its controls or launch another simple modal form to actually launch
the processing thread and display some sort of "I'm running" indicator
until it receives notification (not by polling, by callback) that the
thread has finished.
Your implementation is broken, not the framework. This is not meant
to be snarky, just straightforward .

ce******@ocv.co m wrote:

>Exactly, I am using the BackgroundWorke r (see code snippets) above. In
essence, I am firing off the stored proc and then putting the GUI in a
loop that sleeps for a while, awakens, and updates itself and then goes
back to sleep. This continues until the stored proc returns.

But the trouble is that it (the SleepAndUpdate loop) stops working
after a while. When it first fires up, everything is great and then
after an indeterminate period of time the DoEvents() stops returning.

It is puzzling.

I hate to take the "easy" way out and point to the framework but that
is indeed what it seems like the trouble is.

All helpful thoughts and suggestions (not the snarky ones about "Do
people really still use DoEvents() (is it even valid in C#?).") are
appreciated.

wf****@gmail.co m wrote:

Then you need to just disable the GUI programmiticall y. Thread.Sleep()
on the UI thread is never correct. Look into using the BackgroundWorke r
class for a simple and sound solution if you're using 2.0.

http://msdn2.microsoft.com/en-us/lib...undworker.aspx

[Greg Young]

Have the background thread notify the foreground thread when it is complete
.....

Also you can't continue with the process involving the sproc but can you do
other things while waiting or is the app designed to only do this one
process and the one process doesn't make sense to be doing multiples (i.e.
running a big report).

Cheers,

Greg
<ce******@ocv.c omwrote in message
news:11******** *************@m 73g2000cwd.goog legroups.com...

wfa:

Sorry, I wasn't indicting you. I just get frustrated with condescending
posts.

In any case, the issue is that when the call returns then we must move
onto the next step in the process. We let the stored proc run in the
back ground BUT we can't continue on with processing until the stored
proc returns. That is why we go into a sleep loop. Otherwise, we just
loop until the semaphore is reset.

[e-mail] m wrote:

>Don't sleep on the UI thread. Ever. You're preventing the UI
thread from processing any messages for 1 second. Disable the main form
and its controls or launch another simple modal form to actually launch
the processing thread and display some sort of "I'm running" indicator
until it receives notification (not by polling, by callback) that the
thread has finished.
Your implementation is broken, not the framework. This is not meant
to be snarky, just straightforward .