On Mar 29, 2007, at 2:51 PM, Tim Jones wrote: > 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.
I have firsthand experience with refactoring applications that used App.DoEvents to make them reliable. I've seen the problems with reentrant behavior, locking up, etc. that were present. I worry also that RS is using DoEvents under the hood with sockets, given that I experienced significant problems with unexpected reentrancy and application hangs in the interaction of sockets and the ODBC plugin. > >>> 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. Use App.SleepCurrentThread. > > 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. You have alternatives to App.DoEvents that work consistenly - they're called "threads". If you're thinking in terms of "top-down code flow", then I think you'll always be fighting against the Rb app framework. Charles Yeomans _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
