On 4/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Apr 25, 2007, at 18:21 UTC, Peter K. Stys wrote: > > > First a thread, and now a timer???? What next? > > Nothing's next. There's no step three. In fact, you can eliminate > step 2 (the timer) if you prefer. > > > All we want is: > > > > for j = 1 to 1000000 > > myWindow.myStaticText.text = str(j) > > next > > > > for myStaticText to actually display the progress of the loop as it's > > running (distilled example of course). > > OK, then put this loop in a thread and that's what it'll do. > > > I accept that App.DoEvents is unhealthy, but I second my own vote for > > myWindow.refresh to do what one would expect: to safely update the > > values of all the window's controls so the user can see that > > something is actually happening. > > I hope I'm not one of your users. I don't just expect to see controls > update; I expect the app to remain responsive -- I should be able to > drag windows around (perhaps to get it out of the way while it does its > long work), avoid the spinning wait cursor of death, and so on. > Window.Refresh can't do all that; servicing the main event loop (by not > tying up the main thread) does all that and also what Window.Refresh > could do. It seems clear to me that the proper solution is to not tie > up the main thread, so I don't really see the point of making improper > half-baked solutions work slightly better. > > > We all have frequent instances I'm sure where code is running > > iteratively, in many places and under many windows, so to have a > > thread for each (...then a timer...then...) is needlessly complicated > > IMHO. > > I think you're imagining it to be more complicated than it is. And no, > I don't frequently have instances of such code, but when I do, I throw > a Thread on the window (or if no window is handy, make a Thread > subclass), call the long-running code from there, and it's done. > > > All the suggested workarounds indicate that a simple functionality is > > not implemented correctly. > > I disagree. Your suggested solution indicates to me that you haven't > yet grasped how a GUI, event-driven app works. >
I'm sure I have yet much to learn Joe. Point is, if you put it in a thread, the user can continue doing other stuff, which is not what you may want before this job is done. If you put the thread in a modal dlog, as someone pointed out, the thread may be halted, so no dice. And to answer Marc's question, inserting a myWindow.myStaticText.refresh does not work for composite windows (and if you don't composite some windows they don't draw right, and on, and on...). Maybe my design violates Apple's GUI guidelines, but if there is a myWindow.refresh method, I would expect it to do what it should. And it don't. P. -- ------------------------------------------------------------------------------- Peter K. Stys, MD Professor of Medicine(Neurology), Senior Scientist Ottawa Health Research Institute, Div. of Neuroscience Ottawa Hospital / University of Ottawa Ontario, CANADA tel: (613)761-5444 fax: (613)761-5330 http://www.ohri.ca/profiles/stys.asp ------------------------------------------------------------------------------- _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
