 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Windows Forms / WinForm General / March 2007OK to use DoEvents() ??
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. -- Bryan Phillips MCSD, MCDBA, MCSE Blog: http://bphillips76.spaces.live.com > Hi, > [quoted text clipped - 9 lines] > Thanks, > Dave 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 > It would be a better idea to use the BackgroundWorker class or the > ThreadPool class to run the operation on a separate thread. [quoted text clipped - 22 lines] >> Thanks, >> 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 > 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 [quoted text clipped - 30 lines] >>> Thanks, >>> Dave 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> ---------------------- >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 [quoted text clipped - 41 lines] >>>> Thanks, >>>> Dave > 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...  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too >> But even if he does it in a background worker thread, the documentation >> and [quoted text clipped - 9 lines] > 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. > One thing that was interesting about it. If I have it in there, I can not > kick off my background worker as a function [quoted text clipped - 4 lines] > > ExcelExport.testProgressing(100, worker, e) You mean that just assigning to e.Result is causing an exception? What is "e" in this case? SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too 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. ------------------------------ >> One thing that was interesting about it. If I have it in there, I can >> not [quoted text clipped - 8 lines] > You mean that just assigning to e.Result is causing an exception? What > is "e" in this case? > 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" Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.