| Groups | Blog | Home |
dotnet windows forms : OK to use DoEvents() ??
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
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> ---------------------- [quoted text, click to view] "VJ" <nonewsaddress@yahoo.com> wrote in message news:OeO$iScZHHA.4856@TK2MSFTNGP03.phx.gbl... >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" <dadams@nospam-njs-ent.com> wrote in message > news:ejkLvLcZHHA.4220@TK2MSFTNGP03.phx.gbl... >> 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 >> >> >> >> >> "Bryan Phillips" <bphillips@nospam.spamcop.net.spammenot> wrote in >> message news:OTfWQrbZHHA.348@TK2MSFTNGP02.phx.gbl... >>> 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 >>> >>> >>> >>> "David Adams" <dadams@nospam-njs-ent.com> wrote in message >>> news:uY7e8DaZHHA.3628@TK2MSFTNGP02.phx.gbl: >>> >>>> 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 >>> >> >> > >
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 [quoted text, click to view] "Bryan Phillips" <bphillips@nospam.spamcop.net.spammenot> wrote in message news:OTfWQrbZHHA.348@TK2MSFTNGP02.phx.gbl... > 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 > > > > "David Adams" <dadams@nospam-njs-ent.com> wrote in message > news:uY7e8DaZHHA.3628@TK2MSFTNGP02.phx.gbl: > >> 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 >
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 [quoted text, click to view] "David Adams" <dadams@nospam-njs-ent.com> wrote in message news:ejkLvLcZHHA.4220@TK2MSFTNGP03.phx.gbl... > 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 > > > > > "Bryan Phillips" <bphillips@nospam.spamcop.net.spammenot> wrote in message > news:OTfWQrbZHHA.348@TK2MSFTNGP02.phx.gbl... >> 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 >> >> >> >> "David Adams" <dadams@nospam-njs-ent.com> wrote in message >> news:uY7e8DaZHHA.3628@TK2MSFTNGP02.phx.gbl: >> >>> 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 [quoted text, click to view] "David Adams" <dadams@nospam-njs-ent.com> wrote in message
news:uY7e8DaZHHA.3628@TK2MSFTNGP02.phx.gbl: > 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
[quoted text, click to view]
"David Adams" <dadams@nospam-njs-ent.com> wrote in message news:ejkLvLcZHHA.4220@TK2MSFTNGP03.phx.gbl... > 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"
[quoted text, click to view]
RobinS <RobinS@NoSpam.yah.none> wrote: > 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... -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:MPG.20624a64b8ced68198d98c@msnews.microsoft.com... > RobinS <RobinS@NoSpam.yah.none> wrote: >> 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... > > -- > Jon 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 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.
[quoted text, click to view]
RobinS <RobinS@NoSpam.yah.none> wrote: > 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? -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
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. ------------------------------ [quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:MPG.2063b3418615f16298d9a3@msnews.microsoft.com... > RobinS <RobinS@NoSpam.yah.none> wrote: >> 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? > > -- > Jon 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
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |