OK to use DoEvents() ??

[David Adams]

Hi,

I have an application that recently has received a few complaints because of
slow repainting/refreshing of certain forms. For example, I am throwing up
a messagebox that prompts the user to perform an operation, if the user
clicks yes, I perform the operation which is rather resource intensive. The
problem is the messagebox that was clicked partially remains in the
background after it was clicked (refresh/repaint issue). If I use the old
school DoEvents() it helps but am not sure if this is the best way to solve
this problem.

Thanks,
Dave

 

[Bryan Phillips]

It would be a better idea to use the BackgroundWorker class or the
ThreadPool class to run the operation on a separate thread.

 

[David Adams]

Hi Bryan. Wouldn't that be a bit overkill? I am simply prompting the user
(via MessageBox.Show) to perform an operation and running that operation
based on receiving the DialogResult "yes". The MessageBox failing to
disappear is the problem here.

Thanks for your response.
Dave

 

[VJ]

I think Bryan meant to say do the resource intensive operation in a thread,
so in all when the thread starts, you display a busy cursor. Now would this
take care of messagebox disappearing without DoEvents(), that is debatable.
Depending what you do to imitate the thread... DoEvents() is ok to do.. just
not for every screen refresh you will need it.. Sometimes the best options
is to invalidate ( i.e just repaint a specific region) will do it...

VJ

 

[Michael C]

Hi Bryan. Wouldn't that be a bit overkill?

Not really. I think XP expects apps to do this these days because of the way
it treats apps that are in a tight look as "not responding"

 

[RobinS]

But even if he does it in a background worker thread, the documentation and
examples on MSDN call DoEvents to make sure the UI is still operable.

So I think he should just try using DoEvents and see if it fixes the
problem, and if it does, fine.

Robin S>
----------------------

 

[Jon Skeet [C# MVP]]

But even if he does it in a background worker thread, the documentation and
examples on MSDN call DoEvents to make sure the UI is still operable.

So I think he should just try using DoEvents and see if it fixes the
problem, and if it does, fine.

If you're not blocking the UI thread, there should be no need to call
DoEvents at all. Could you give an example of such documentation?

Threading issues should not be solved by just trying something - it's
too easy to end up with code which will work *most* of the time. You
know - until a customer ends up with it...

 

[RobinS]

If you're not blocking the UI thread, there should be no need to call
DoEvents at all. Could you give an example of such documentation?

Threading issues should not be solved by just trying something - it's
too easy to end up with code which will work *most* of the time. You
know - until a customer ends up with it...

Well, this is the article I was thinking of, but you're right, it doesn't
say anything about DoEvents.

http://msdn2.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx

I seem to vaguely remember that when I implemented my version of this, if I
didn't put a DoEvents in, my UI was nonresponsive, maybe my Cancel button
didn't work or something like that. I'll try taking it out and see what it
does.

One thing that was interesting about it. If I have it in there, I can not
kick off my background worker as a function

e.Result = ExcelExport.testProgressing(100, worker, e)

This will cause an exception. But I can run it this way:

ExcelExport.testProgressing(100, worker, e)

Interesting.

Robin S.

 

[Jon Skeet [C# MVP]]

One thing that was interesting about it. If I have it in there, I can not
kick off my background worker as a function

e.Result = ExcelExport.testProgressing(100, worker, e)

This will cause an exception. But I can run it this way:

ExcelExport.testProgressing(100, worker, e)

You mean that just assigning to e.Result is causing an exception? What
is "e" in this case?

 

[RobinS]

e is the ProcessChangedEventArgs.

I went back and looked at the code again, and tried the line before again,
and now it doesn't have any problem at all, whether I have DoEvents in
there or not. And the DoEvents no longer seems necessary either. (insert
Twilight Zone music here).

The only thing I changed was I was mucking around with OOP and changed the
class from a static class to a non-static class so you have to instantiate
it. I really think it should be a static class, because all it does it
create a report, and they can not run more than one simultaneously, but I
was mucking around.

I'm going to change it back to a static class and see if it makes any
difference.

Maybe I inadvertently fixed it somehow. It was my first foray into
threading and I was going back and forth trying different things.

I'll report back.

Robin S.