🌐 Mailman 3 May 1997 - Pythonmac-SIG - python.org

Re:[PYTHONMAC-SIG] apps freeze unless they print!
by Joseph J. Strout May 19, 1997

May 19, 1997

Bill wrote: >Not quite true, replace the print line with > >if t % 10 == 0:print t Yes, I know this, but in my app I don't WANT to print anything when there's nothing going on -- not even every 10 seconds. >The Mac guts are being up dated, but you are putting null events into the >console's event queue and these are having to time out before it redraws. > >One way round would be to use MacOS.SetScheduleTimes() to make the console >check the event queue more often and so speed up the redraw. Hmm, I tried reducing it from the default value (12) to 2, with no effect. It's as if it never checks the event queue at all, until I hit command-period. Regards, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Department of Neuroscience, UCSD | | jstrout(a)ucsd.edu http://www-acs.ucsd.edu/~jstrout/ | `------------------------------------------------------------------' _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0

Re: [PYTHONMAC-SIG] apps freeze unless they print!
by just＠knoware.nl May 18, 1997

May 18, 1997

At 2:07 PM 5/18/97, Joseph J. Strout wrote: >I'm suddenly finding that Python locks up under the following conditions: I >have a program in a loop which is working very hard (or snoozing) for a >long time without printing anything to the console window (sample code >below); I switch to the Finder or any other app; then I switch back -- >presto, it's frozen. By "frozen" I mean that the window is not refreshed, >I can't move it, and I can't switch back to the Finder or any other app; I >have to hit command-period or kill the Python process. Hm, I'm not getting exactly the same what you describe. My window does not get updated, but I can move it and I can go back and forth between apps no problem. The not updating thing is annoying indeed. I found the reason in macglue.c: /* ** We have to be careful, since we can't handle ** things like updates (and they'll keep coming back if we don't ** handle them). Note that we don't know who has windows open, so ** even handing updates off to SIOUX under MW isn't going to work. */ #define MAINLOOP_EVENTMASK (mDownMask|keyDownMask|osMask) Can't we check whether there are custom windows? Say, disable update events as soon as Win.GetNewWindow() and relatives are used? Hmm, not "safe" when a C-extension makes it's own windows. But then again, then you're probably running a custom event loop already. I'd say, if the Appswitching var has the default value (1), there's only small chance there are any other windows open besides SIOUX. Perhaps a new option for MacOS.EnableAppswitch()? So, if you want updates to be handled correctly while a script is running, do MacOS.EnableAppswitch(2). It couldn't be turned on by default I think. I wish I could do Appswitching while a script is running in a FrameWork environment (with all event handling done in Python), but I think we need thread support to do that... Just _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0

Re: [PYTHONMAC-SIG] A bugfix for ped and a question (possibly long answer)
by just＠knoware.nl May 16, 1997

May 16, 1997

>class TAValue: > > tr = 0, 0, 0, 0 > testTE = TE.TENew(tr, tr) #kills me stone dead > del tr > > def TryNewTEChar(self, ch): > dhandle = self.TEGetText() > data = dhandle.data > TAValue.testTE.TESetText(data) > TAValue.testTE.TESetSelect(self.selStart, self.selEnd) > TAValue.testTE.TEKey(ord(ch)) > dhandle = TAValue.testTE.TEGetText() > return dhandle.data > > def __init__(self, x0, y0, x1, y1): > #lots more > >The idea was that testTE is a class attribute that gets set up as the file >is read in. Then I can use it in TryNewTEChar to do character by character >filtering and updating as the user types. I've been doing this in C (with >a global variable rather than a class attribute) for years now, so I know >it works. Well, the line testTE = TENew(tr, tr) blasts my Mac into another >world. The cursor freezes, and bucky/escape won't kill the application. I >have to power down and back up. Is this because TE is not Python but is >glued in from the toolbox, or have I completely misunderstood about class >methods and attributes? TENew picks the current GrafPort to live in, which is probably the SIOUX window in your case. I don't know why that still crashes as bad as it does, but I've seen it happen indeed. How do you do this in C? (Kindof wondering since I have not used TE much in C.) Do you set the GrafPort later manually? If so, you can't do that in Python I think. >Or should I be looking somewhere else? I looked through the archive of >this group last weekend, and saw one, maybe two references to this >FrameWork. I wonder whether that means that you guys use something else, >like Tk or wxWindows. I've even thought about hacking my C stuff into >waste and adding glue for it. But that means that I have to stop what I'm >doing and go learn how to do that. I use FrameWork a lot, but I have written a more abstract layer on top of it. FrameWork is already a lot more abstract than the toolbox, but it's still very cumbersome to make windows, controls, etc. I plan to release my stuff, since I'm sure other people might find it useful, but it's not yet generic enough. >I can do my prototyping without input filtering if I remember to type >carefully when I'm testing, but it would be nice to have it. Any >suggestions? Isn't customizing the 'do_char' method of FrameWork.Window enough? Just _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0

A bugfix for ped and a question (possibly long answer)
by James B. Wilkinson May 15, 1997

May 15, 1997

In the method do_contentclick of class TEWindow the line shifted = (modifiers & 0x200) should be shifted = (modifiers & 0x200) != 0 to get correct selection extension with the shift key. I think that what is going on is that the Mac toolbox (because of its Pascal origins?) wants the value 1 for true, and no ordinary nonzero value (like the 512 you get with the incorrect line) will do. You were all waiting breathlessly for this one to be fixed, right? Now here's my question. I put the following code into a class I made: class TAValue: tr = 0, 0, 0, 0 testTE = TE.TENew(tr, tr) #kills me stone dead del tr def TryNewTEChar(self, ch): dhandle = self.TEGetText() data = dhandle.data TAValue.testTE.TESetText(data) TAValue.testTE.TESetSelect(self.selStart, self.selEnd) TAValue.testTE.TEKey(ord(ch)) dhandle = TAValue.testTE.TEGetText() return dhandle.data def __init__(self, x0, y0, x1, y1): #lots more The idea was that testTE is a class attribute that gets set up as the file is read in. Then I can use it in TryNewTEChar to do character by character filtering and updating as the user types. I've been doing this in C (with a global variable rather than a class attribute) for years now, so I know it works. Well, the line testTE = TENew(tr, tr) blasts my Mac into another world. The cursor freezes, and bucky/escape won't kill the application. I have to power down and back up. Is this because TE is not Python but is glued in from the toolbox, or have I completely misunderstood about class methods and attributes? Or should I be looking somewhere else? I looked through the archive of this group last weekend, and saw one, maybe two references to this FrameWork. I wonder whether that means that you guys use something else, like Tk or wxWindows. I've even thought about hacking my C stuff into waste and adding glue for it. But that means that I have to stop what I'm doing and go learn how to do that. I can do my prototyping without input filtering if I remember to type carefully when I'm testing, but it would be nice to have it. Any suggestions? Thanks. ------------------------------------------------------------- Jimmy Wilkinson | Perfessor of Computer Science jimmy(a)cs.cofc.edu | The College of Charleston (803) 953-8160 | Charleston SC 29424 If there is one word to describe me, that word would have to be "profectionist". _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0

Re: [PYTHONMAC-SIG] CW11 (again)
by Jack Jansen May 15, 1997

May 15, 1997

> Has anyone done the CW11 rebuild of Python1.4 yet ? > Any problems ? If you load the "obsolete ANSI libraries" from the CW11 CD and use those in stead of MSL it should build fine. Don't bother trying to convert to MSL: I've already done it and it is an *incredible* amount of excruciatingly boring work (I spent the better part of two weeks on it). > I've finally got a need to rebuild it -- I'm working my > way thru a handful of Tcl/Tk 8 changes in libraries and > access paths to get it to recompile, and I may get around > to starting on Python tonight. Could you keep me updated on what you've had to change? I haven't looked at Tcltk 8 yet, but will do so shortly... > BTW: I saw a mention of 1.5a1 in the string sig, but I > didn't see this on the ftp site anywhere. Any chance of > getting a copy to start on Mac CW11 + TK8 mods - or is > Jack or someone started on this already ? Yup, it's being done. As soon as Guido clears 1.5a-something for general distribution I'll do a mac distribution. > BTWII: It would be nice to have a more light-weight distribution > ( both source and binary ) that, for example, that just expected > Tcl/Tk shared libraries to be installed separately in "the usual > place" . Anyone have any ideas or suggestions about this ? Hmm, probably a good idea, now that there's the tcl/tk shared libraries. Why don't you give it a try? > BTWIII: > How much of GUSI is needed now -- I know it's required for > socket support, but I think a lot of others posix like things > may now be supported in both GUSI and MSL. ( and I noticed > that GUSI has been taken out of the Tcl/Tk 8.0 distribution. > -- and, I've been unable for some time, to connect to the GUSI > ftp site to check on the status of newer versions. ) Beside sockets GUSI also provides select, better "raw" I/O and the hooks for multiple threads (eventually). I'd be reluctant to do away with it, the MSL library is not really that much better than the old ANSI library. GUSI currently lives at <ftp://sunsite.cnlab-switch.ch/software/platform/macos/ src>. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

3 2

CW11 (again)
by Steven D. Majewski May 14, 1997

May 14, 1997

Has anyone done the CW11 rebuild of Python1.4 yet ? Any problems ? I've finally got a need to rebuild it -- I'm working my way thru a handful of Tcl/Tk 8 changes in libraries and access paths to get it to recompile, and I may get around to starting on Python tonight. BTW: I saw a mention of 1.5a1 in the string sig, but I didn't see this on the ftp site anywhere. Any chance of getting a copy to start on Mac CW11 + TK8 mods - or is Jack or someone started on this already ? BTWII: It would be nice to have a more light-weight distribution ( both source and binary ) that, for example, that just expected Tcl/Tk shared libraries to be installed separately in "the usual place" . Anyone have any ideas or suggestions about this ? BTWIII: How much of GUSI is needed now -- I know it's required for socket support, but I think a lot of others posix like things may now be supported in both GUSI and MSL. ( and I noticed that GUSI has been taken out of the Tcl/Tk 8.0 distribution. -- and, I've been unable for some time, to connect to the GUSI ftp site to check on the status of newer versions. ) ---| Steven D. Majewski (804-982-0831) <sdm7g(a)Virginia.EDU> |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- By doing just a little every day, you can gradually let the task completely overwhelm you. _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0

Re: [PYTHONMAC-SIG] ped/framework weirdness
by just＠knoware.nl May 14, 1997

May 14, 1997

At 11:09 AM 5/14/97, Jack Jansen wrote: >> I was hoping to use the framework to do some experimenting with a project >> I've been working on. Finally got sick of trying to do it in C. So I >> started trying out the framework last week, and ped looked like a good >> place to start since I want to use TE boxes. The do_activate method in the >> TEWindow class has a line print "ACTIVATE", onoff right at its >> beginning. I noticed that if I open two new windows in ped and click back >> and forth between them, the print statement shows only *deactivate* events >> in the Python output window: "ACTIVATE 0". > >Hmm, you're right. I'm not sure exactly what's going on, but I suspect that >it has to do with the debug output: printing causes Sioux to run, and it may >eat some events in that case. Try removing all print statements. It took me a while, but that's exactly it. Some events were being eaten by SIOUX (the Metroworks console that just doesn't stop to suck), which has it's own event handling stuff, even though it was't supposed to do so: MacOS.EnableAppswitch(-1) was performed in FrameWork, which means that no event should be passed to SIOUX. But, (and this I didn't know), it still eats events during printing... Solution: omit the print statements and you're fine, although the scrollbars still behave a bit strange, but I guess that's ped's or FrameWork.ScrolledWindow's fault (left as an excercise). Besides that, we can fully blame SIOUX. >Another possibility is to look at the waste demos, they show the correct >behaviour. These were adapted from ped, so the code is similar. I don't have >the >time right now to check out what I did correctly in those and wrong in ped, >though, so you're on your own. Waste rocks. It's excellent. Builtin undo. Some tab support. Very flexible. This is supposed to sound cheesy, but it's true: Since I discovered WASTE, I never even looked at TE again... Just _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

2 2

Re: [PYTHONMAC-SIG] ped/framework weirdness
by Jack Jansen May 14, 1997

May 14, 1997

> I was hoping to use the framework to do some experimenting with a project > I've been working on. Finally got sick of trying to do it in C. So I > started trying out the framework last week, and ped looked like a good > place to start since I want to use TE boxes. The do_activate method in the > TEWindow class has a line print "ACTIVATE", onoff right at its > beginning. I noticed that if I open two new windows in ped and click back > and forth between them, the print statement shows only *deactivate* events > in the Python output window: "ACTIVATE 0". Hmm, you're right. I'm not sure exactly what's going on, but I suspect that it has to do with the debug output: printing causes Sioux to run, and it may eat some events in that case. Try removing all print statements. Another possibility is to look at the waste demos, they show the correct behaviour. These were adapted from ped, so the code is similar. I don't have the time right now to check out what I did correctly in those and wrong in ped, though, so you're on your own. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0

ped/framework weirdness
by James B. Wilkinson May 13, 1997

May 13, 1997

I was hoping to use the framework to do some experimenting with a project I've been working on. Finally got sick of trying to do it in C. So I started trying out the framework last week, and ped looked like a good place to start since I want to use TE boxes. The do_activate method in the TEWindow class has a line print "ACTIVATE", onoff right at its beginning. I noticed that if I open two new windows in ped and click back and forth between them, the print statement shows only *deactivate* events in the Python output window: "ACTIVATE 0". Furthermore, the behavior of the grow boxes correlates with that. Once they are gone they don't come back unless I click in some other window, like the Python output window. Then, when I click back in one of the editor windows, I get an activate event in it and the grow box comes back. Hmmm. So I decided to put a print into the dispatch method in the framework and see what's going on. Well, that fixed the problem!!! I started seeing both deactivate and activate events (from the print line in do_activate). So I started moving it around in the dispatch method. Got the most interesting results with it at the bottom: #print 'dispatch', name handler(event) #this is the last true line of code in the method #print 'dispatch', name Like this it acts as I described in the first paragraph. If I remove the # on the line before the handler call, everything works as I think it should. If I put it back there and remove the # on the last line, then I get only *activate* events when I click back and forth between two ped windows: "ACTIVATE 1". I'm totally confused. If this were happening in C, I'd know what it meant, but in an interpreted language? Anybody got any ideas about what's going on here? Contributions gratefully accepted. ------------------------------------------------------------- Jimmy Wilkinson | Perfessor of Computer Science jimmy(a)cs.cofc.edu | The College of Charleston (803) 953-8160 | Charleston SC 29424 If there is one word to describe me, that word would have to be "profectionist". _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0

New improved ProgressBar [ MacPython EasyDialogs.py ]
by Steven D. Majewski May 11, 1997

May 11, 1997

I had some time in between projects, while waiting for a vendor to deliver some new drivers, to try to finish up some old half-finished projects. Since Python 1.5 is impending, I thought I'ld try to clean up my changes to EasyDialogs and try to get Guido & Jack to include it in the next Mac Python distribution. ( Jack -- please remember about the changes to the template to allow all files rather than just TEXT files. I have some template Mac file-munger applications that I would like to distribute, and those changes and these below are the things that have kept me from doing it -- I wanted it to be a simple MacPython example, but having to drag out ResEdit right away keeps it from being a simple procedure. ) Here is a new version of EasyDialogs.py with an improved ProgressBar class, which handles Drag events ( so you should change the window type of the resource to a movable modal dialog type window -- the one with a wider drag region, but no close or zoom boxes. ) and clicking on the Cancel/Stop button. I would like to add a second label line. When I tried using this in some file conversion programs, and I wanted to echo pathnames, it often overflowed the space for the text. Most of the progress bars generated by the finder and various utilities like Stuff-it, etc. all have two lines of text. Any preferences towards either allowing PB.label( string1, string2 ) vs. PB.label1( text ) & PB.label2( text ) ? I'm also considering changing the resource numbers to more closely follow Mac conventions - for example, Cancel or Stop button should usually be = 2 as Cancel is defined in some headers to be that value. I don't think changing the resource numbers should have any effect outside this code. Previous changes from EasyDialogs in 1.4 distribution: Changed Progress.Bar.label from an attribute to a method. ProgressBar.label() [with no args] returns the label. ProgressBar.label( text ) sets the label string and causes dialog update. Added ProgressBar.inc( *amount ) to increment the bar and redraw/update. A couple of bug fixes -- one that cures occasional crash on update. Latest changes: ProgressBar._update() handles drag and cancel events. You need to ResEdit the progress bar dialog resource in PythonCore: [1] The cancel button must be enabled. ( Required ) [2] Change the window to a movable dialog type. ( Highly Recommended ) [3] Change the button text from "Cancel" to "Stop" ( Recommended by Mac HI guidelines as less ambiguous ) ( #1 above kept me confused about why some of the dialog routines didn't work as I expected. It seems to have been shipped as disabled in the distribution. ) Comments or suggestions ? -- Steve Majewski """Easy to use dialogs. Message(msg) -- display a message and an OK button. AskString(prompt, default) -- ask for a string, display OK and Cancel buttons. AskYesNoCancel(question, default) -- display a question and Yes, No and Cancel buttons. bar = Progress(label, maxvalue) -- Display a progress bar bar.set(value) -- Set value bar.inc( *amount ) -- increment value by amount (default=1) bar.label( *newlabel ) -- get or set text label. More documentation in each function. This module uses DLOG resources 256, 257 and 258. Based upon STDWIN dialogs with the same names and functions. """ from Dlg import GetNewDialog, SetDialogItemText, GetDialogItemText, ModalDialog import Qd import QuickDraw import Dlg,Win,Evt,Events # sdm7g def Message(msg): """Display a MESSAGE string. Return when the user clicks the OK button or presses Return. The MESSAGE string can be at most 255 characters long. """ id = 256 d = GetNewDialog(id, -1) if not d: print "Can't get DLOG resource with id =", id return tp, h, rect = d.GetDialogItem(2) SetDialogItemText(h, msg) d.SetDialogDefaultItem(1) while 1: n = ModalDialog(None) if n == 1: return def AskString(prompt, default = ""): """Display a PROMPT string and a text entry field with a DEFAULT string. Return the contents of the text entry field when the user clicks the OK button or presses Return. Return None when the user clicks the Cancel button. If omitted, DEFAULT is empty. The PROMPT and DEFAULT strings, as well as the return value, can be at most 255 characters long. """ id = 257 d = GetNewDialog(id, -1) if not d: print "Can't get DLOG resource with id =", id return tp, h, rect = d.GetDialogItem(3) SetDialogItemText(h, prompt) tp, h, rect = d.GetDialogItem(4) SetDialogItemText(h, default) # d.SetDialogItem(4, 0, 255) d.SetDialogDefaultItem(1) d.SetDialogCancelItem(2) while 1: n = ModalDialog(None) if n == 1: tp, h, rect = d.GetDialogItem(4) return GetDialogItemText(h) if n == 2: return None def AskYesNoCancel(question, default = 0): ## """Display a QUESTION string which can be answered with Yes or No. ## ## Return 1 when the user clicks the Yes button. ## Return 0 when the user clicks the No button. ## Return -1 when the user clicks the Cancel button. ## ## When the user presses Return, the DEFAULT value is returned. ## If omitted, this is 0 (No). ## ## The QUESTION strign ca be at most 255 characters. ## """ id = 258 d = GetNewDialog(id, -1) if not d: print "Can't get DLOG resource with id =", id return # Button assignments: # 1 = default (invisible) # 2 = Yes # 3 = No # 4 = Cancel # The question string is item 5 tp, h, rect = d.GetDialogItem(5) SetDialogItemText(h, question) d.SetDialogCancelItem(4) if default == 1: d.SetDialogDefaultItem(2) elif default == 0: d.SetDialogDefaultItem(3) elif default == -1: d.SetDialogDefaultItem(4) while 1: n = ModalDialog(None) if n == 1: return default if n == 2: return 1 if n == 3: return 0 if n == 4: return -1 screenbounds = Qd.qd.screenBits.bounds screenbounds = screenbounds[0]+4, screenbounds[1]+4, \ screenbounds[2]-4, screenbounds[3]-4 class ProgressBar: def __init__(self, label="Working...", maxval=100): self.maxval = maxval self.curval = -1 self.d = GetNewDialog(259, -1) self.label( label ) self._update(0) def __del__( self ): self.d.HideWindow() del self.d def label( self, *newstr ): # sdm7g -- new routine: change text if newstr : self._label = newstr[0] tp, text_h, rect = self.d.GetDialogItem(2) SetDialogItemText(text_h, self._label ) def _update(self, value): self.d.BringToFront() # sdm7g -- this seems to cure Modal bus-error crash tp, h, bar_rect = self.d.GetDialogItem(3) Qd.SetPort(self.d) Qd.FrameRect(bar_rect) # Draw outline inner_rect = Qd.InsetRect(bar_rect, 1, 1) l, t, r, b = inner_rect Qd.ForeColor(QuickDraw.blackColor) Qd.BackColor(QuickDraw.blackColor) Qd.PaintRect((l, t, int(l + (r-l)*value/self.maxval), b)) # Draw bar Qd.ForeColor(QuickDraw.whiteColor) Qd.BackColor(QuickDraw.whiteColor) Qd.PaintRect((int(l + (r-l)*value/self.maxval), t, r, b)) # Clear rest # Restore settings Qd.ForeColor(QuickDraw.blackColor) Qd.BackColor(QuickDraw.whiteColor) # Test for cancel button ready, ev = Evt.WaitNextEvent( Events.mDownMask, 1 ) if ready : what,msg,when,where,mod = ev part = Win.FindWindow( where )[0] if Dlg.IsDialogEvent( ev ): ds = Dlg.DialogSelect( ev ) if ds[0] and ds[1] == self.d and ds[-1] == 1 : raise KeyboardInterrupt, ev else: if part == 4 : # inDrag self.d.DragWindow( where, screenbounds ) else: MacOS.HandleEvent( ev ) def set(self, value): if value < 0: value = 0 if value > self.maxval: value = self.maxval self.curval = value # sdm7g -- didn't update curval self._update(value) def inc( self, *n ): # sdm7g -- add increment method if not n: n = 1 else: n = n[0] self.set( self.curval + n ) import time import MacOS def test(): Message("Testing EasyDialogs.") ok = AskYesNoCancel("Do you want to proceed?") if ok > 0: s = AskString("Enter your first name") Message("Thank you,\015%s" % `s`) text = ( "Working Hard...", "Hardly Working..." , "So far, so good!", "Keep on truckin'" ) bar = ProgressBar( text[0], 100) try: appsw = MacOS.EnableAppswitch( 0 ) for i in range(100): bar.set(i) time.sleep( 0.1 ) if ( i % 10 == 0 ) : bar.label( text[ (i/10) % 4 ] ) bar.label( "Done." ) time.sleep( 0.3 ) # give'em a chance to see the done. finally: del bar MacOS.EnableAppswitch( appsw ) if __name__ == '__main__': try: test() except KeyboardInterrupt: Message( "Operation Canceled." ) _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0