On Mar 29, 2007, at 2:51 PM, Tim Jones wrote:
> On Mar 29, 2007, at 9:33 AM, joe at strout dot net 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>
|