On Mar 29, 2007, at 12:26 PM, Charles Yeomans wrote:
> 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.
Again, a nice description, but nothing that I can look at and say
"yep - that's a real problem when I run it". Remember, your mom
warned you about "those girls" when you were 14, also. And "those
girls" turned out to be the most fun ;-/
I guess that I should also add that I use booleans in my operations
that could be clobbered by unexpected re-entrant calls (sockets,
shells, and a few self-built looping methods) to prevent the loop
from being entered if it was already running - in pseudocode:
If Not theControlIsActive Then
theControlIsActive = True
// do the loop stuff
theControlIs Active = False
Else
Return
End If
(The return isn't really necessary, but it keeps the code clean) So
this may be another reason that I've not had to test my "helmet" :-).
[SNIP about Modal Window]
>> Also, a Pause() function would be handy
[SNIP]
> Use App.SleepCurrentThread.
Okay - just tried this and a simple thread that counts to 1000 that
is a child of the parent window pauses for the 2 seconds that I've
instructed SleepCurrentThread() to wait in a Do -- Loop.
Window1.Open:
thLoop.Run
Do
App.SleepCurrentThread(2000)
Done
thLoop.Run:
Dim i As Integer
Do
i = i + 1
Window1.Statictext1.Text = "Loop is at " + Str(i)
Loop Until i >=1001
That doesn't seem to be the answer.
>> 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.
And, as mentioned previously, the reasons for controlling flow
through certain operations seems to lie in a no-man's land where the
Thread allows the GUI to update, but also allows the user to do
things that could otherwise be detrimental to the completion of those
operations. And, using a modal window to block the user appears to
also block the thread (in some, unexpected situations)... this is why
I like Peter's note about a new function that would simply update the
various controls displayed without any re-entrant issues such as
polling the event queue.
Ah well, I understand reentrancy issues and why you and RS would be
concerned, but I also know what we're trying to accomplish that can't
apparently be done with the current functionality provided.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
