OK to use DoEvents() ??

  • Thread starter Thread starter David Adams
  • Start date Start date
D

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
 
It would be a better idea to use the BackgroundWorker class or the
ThreadPool class to run the operation on a separate thread.
 
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
 
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
 
David Adams said:
Hi Bryan. Wouldn't that be a bit overkill?
Click to expand...

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"
 
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>
----------------------
 
RobinS said:
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.
Click to expand...

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...
 
Jon Skeet said:
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...
Click to expand...

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.
 
RobinS said:
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)
Click to expand...

You mean that just assigning to e.Result is causing an exception? What
is "e" in this case?
 
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.
 
Back
Top