brian@ut-sally.UUCP (Brian H. Powell) (08/04/87)
Okay, next question. How do you figure out if TextEdit had problems
carrying out some operation?
I've been pushing my program to the limit to try to iron out what happens
when it gets low on memory. When I do a TEPaste, for instance, with memory
very full, I usually get garbage displayed in addition to the text that it's
pasting. MemError doesn't say anything, and of course the TE procedures don't
return any error code. (In case you're wondering, I'm pasting just under 32K
bytes into an empty edit window.)
How's the best way to handle this? Should I leave a large chunk of
memory free so that nothing should ever fail for lack of memory? Is there
something I can check in the TE record that might help me figure out if
something went wrong? (e.g., comparing the teLength after a paste to make
sure the size actually increased by the proper value... Can I really depend
on this?)
Thanks for any help.
Brian H. Powell
UUCP: {ihnp4,seismo,ctvax}!ut-sally!brian
ARPA: brian@sally.UTEXAS.EDU
_Work_ _Not Work_
Department of Computer Sciences P.O. Box 5899
Taylor Hall 2.124 Austin, TX 78763-5899
The University of Texas at Austin (512) 346-0835
Austin, TX 78712-1188
(512) 471-9536stew@endor.harvard.edu (Stew Rubenstein) (08/06/87)
In article <8654@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: > > Okay, next question. How do you figure out if TextEdit had problems >carrying out some operation? > > I've been pushing my program to the limit to try to iron out what happens >when it gets low on memory. After much work trying to handle all the out-of-memory cases and being totally scrupulous about checking MemError every time I turn around, I gave up. My conclusion after much work trying to deal with running out of memory is: don't. What I do is keep a big chunk around and release it in my GrowZone function. If the buffer can't be reallocated the next time through the event loop, I put up an alert and disable everything but save. If the GrowZone gets called, and the buffer has already been deallocated, my program issues prayers to Hertzfeld, Atkinson, and the Woz, unloads every segment but CODE 1 (where the main program, the growzone function, and all functions needed to save files reside), saves the user's documents in filenames like "Budget Worksheet (save1)", and ExitToShell(). My ResumeProc calls the same function (you gotta SetupA5 and UseResFile(myAppFile) first). You do have a GrowZone and ResumeProc, don't you? Stew Stew Rubenstein Cambridge Scientific Computing, Inc. UUCPnet: seismo!harvard!rubenstein CompuServe: 76525,421 Internet: rubenstein@harvard.harvard.edu MCIMail: CSC
lsr@apple.UUCP (Larry Rosenstein) (08/07/87)
In article <2651@husc6.UUCP> stew@endor.UUCP (Stew Rubenstein) writes: > >If the GrowZone gets called, and the buffer has already been deallocated, >my program issues prayers to Hertzfeld, Atkinson, and the Woz, unloads >every segment but CODE 1 (where the main program, the growzone function, >and all functions needed to save files reside), saves the user's documents >in filenames like "Budget Worksheet (save1)", and ExitToShell(). My >ResumeProc calls the same function (you gotta SetupA5 and >UseResFile(myAppFile) first). I hope you use the Prayer Manager to be sure that you are compatible with future systems! (:-) Alternatively, you can keep another reserve block in memory which is the maximum memory you need to operate the essentials of your application. This means enough memory to clear things from a document, save documents, quit, etc. When your initial reserve is deallocated, you have to prevent the user from increasing the memory usage of the application (eg, by disabling commands). Because you have reserved the other memory, however, the user should be able to save the documents normally and regain some memory. This is a very simplified description of what we do in MacApp to solve this problem. One of the trickier details involves how to manage this second reserve block so that memory is used effectively. For example, an unlocked code segment in memory is just as effective in reserving essential application space because it can be purged at any time. Therefore, you can reduce the reserve handle size by the size of all the unlocked code segments. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com