On Mar 29, 2007, at 4:22 PM, Tim Jones wrote: > 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" :-).
I don't have the time to write an application that demonstrates problems with App.DoEvents. I've said what my experience is. > > [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. And I am fairly certain that it can. Jon Johnson has a nice little article on his blog site that explains one way to set up a thread + GUI updating. Essentially, the thread object publishes information, and the window reads it from a Timer. I've long used a similar scheme in one of my applications. But you and Peter introduce the additional requirement of blocking user input while the thread is running. This is more work, and I don't know of a one-click method for doing it. You'd need to design things so that controls and menu items check to see whether the thread is running before allowing user input. In the course of replying I have written an example for myself that does exactly this -- it runs a thread; the user interface is updated by a timer to reflect the current thread state, and other user interaction is blocked. Charles Yeomans _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
