On Mar 29, 2007, at 9:33 AM, [EMAIL PROTECTED] wrote: > On Mar 29, 2007, at 15:40 UTC, Peter K. Stys wrote: > >> At the same time, most often i want to run a batch operation like >> John, and all i want is the progressBar or a staticText value to be >> updated. So I use App.DoEvents, with no obvious issues. > > Ow! Reminds me of the guys driving down the freeway at 80MPH on > motorcycles without helmets. They haven't run into any obvious issues > yet either.
We keep hearing about the potential hazards of using App.DoEvents(), but no hard factual evidence. How about an example that demonstrates an obvious issue? Granted, I've worn a helmet since I was 5 riding on the back of my cousin's minibike - and will continue to wear one even though AZ does require it), but I haven't hit any "issues" there either that made the helmet more than an obstacle to my vision... If you want to use analogies, this FUD about App.DoEvents() feels sort of like scaring teens that have never had sex with STD stories. >> RS says don't!, use a thread instead. but I need my batch operation >> to run synchronously with the rest of my app (ie. user can't >> continue doing anything else until the batch finishes). So now what? > > So you display a modal dialog. That's what they're for. And, I've witnessed the Modal dialog halting the thread along with everything else on too many occasions - I've spun this one 6 ways to Sunday with no luck. Once I close the Modal, the thread continues. >> I understand how App.doEvents could be hazardous to your health. >> Instead, wouldn't it be just plain nice and simple if my loop could >> call myWindow.refresh at each iteration and this would simply do what >> everyone expects it to do: update the state of all controls in said >> window? > > No, it wouldn't, because your users would still be unable to browse > the > menus, or move the window, or avoid the Spinning Beachball of Apparent > Death, or otherwise have a pleasant user experience. And a modal window does allow those things? Okay, then what's the solution? Threads would be great if they weren't apparently tied to their parent so tightly. Seems to be related to this bug report that's apparently not fixed as reported (circa 5.5): http://realsoftware.com/feedback/jotiuqrm Also, a Pause() function would be handy (another thing I've used DoEvents() for) so that we could slow some processes down a bit (such as letting the user know as things progress in a non-time-critical sequence. Sometimes it's more important that the user see that each piece of a sequence occurs, but the newer (hardware) systems cam execute things too quickly to update the information for the user in a useful manner without some sort of delay mechanism. I know there is a Carbon Declare for Delay, but that's synchronous and the app freezes for the period specified. I would love to have an alternative to App.DoEvents() that worked consistently, but until then, as long as you're working in a top-down code flow as Peter and I apparently do, App.DoEvents() is all we've got. Tim -- Tim Jones [EMAIL PROTECTED] _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
