|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
OK 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. Show quote "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 Show quote "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 Show quote "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 >> > > 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> ---------------------- Show quote "VJ" <nonewsaddr***@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 >>> >> >> > > RobinS <RobinS@NoSpam.yah.none> wrote:
> But even if he does it in a background worker thread, the documentation and If you're not blocking the UI thread, there should be no need to call > 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. 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 - <sk***@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
Show quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message Well, this is the article I was thinking of, but you're right, it doesn't 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 - <sk***@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 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 <RobinS@NoSpam.yah.none> wrote:
> One thing that was interesting about it. If I have it in there, I can not You mean that just assigning to e.Result is causing an exception? What > 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) is "e" in this case? -- Jon Skeet - <sk***@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. ------------------------------ Show quote "Jon Skeet [C# MVP]" <sk***@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 - <sk***@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 "David Adams" <dadams@nospam-njs-ent.com> wrote in message Not really. I think XP expects apps to do this these days because of the way news:ejkLvLcZHHA.4220@TK2MSFTNGP03.phx.gbl... > Hi Bryan. Wouldn't that be a bit overkill? it treats apps that are in a tight look as "not responding"  |
|||||||||||||||||||||||
Other interesting topics