home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / mac / programm / 18743 < prev    next >
Encoding:
Text File  |  1992-11-20  |  3.4 KB  |  79 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!news.udel.edu!bach.udel.edu!kurisuto
  3. From: kurisuto@bach.udel.edu (Sean J. Crist)
  4. Subject: A few questions on this and that
  5. Message-ID: <By1vn3.Ctv@news.udel.edu>
  6. Sender: usenet@news.udel.edu
  7. Nntp-Posting-Host: bach.udel.edu
  8. Organization: University of Delaware
  9. Date: Sat, 21 Nov 1992 05:09:02 GMT
  10. Lines: 67
  11.  
  12. Greetings all.  The following questions probably don't warrant 
  13. separate postings, so I'm putting them together into one.  
  14. Questions 1-4 are probably answered in some obscure corner of 
  15. IM, but I don't know where exactly to look.  
  16.  
  17. 1.  If I'm *shrinking* a handle with SetHandleSize, I don't have 
  18. to bother calling MemError, right?  There's no possible way that 
  19. shrinking a handle could could cause me to run out of memory, 
  20. right?  (Let's make the asumption that I know that the handle is 
  21. valid going in.)
  22.  
  23. 2.  If I'm checking MemError, do the contents stay the same no 
  24. matter how many times I call it (i.e., until the next Memory 
  25. Manager call)?  Or is it a one-shot call which will give unreliable 
  26. results the second time you call it?  For example, I want to do this:
  27.  
  28.        AHandle := NewHandle(100);
  29.        if MemError <> 0 then
  30.               doOSErr(MemError);  {A procedure I've defined}
  31.  
  32. Is this OK, or do I have to do this:
  33.  
  34.        var Result : OSErr;
  35.  
  36.        AHandle := NewHandle(100);
  37.        Result := MemError;
  38.        if Result <> 0 then
  39.               doOSErr(Result);
  40.  
  41. 3.  IM warns that menus must not be purged, or a system error will 
  42. occur.  However, said crash can only occur if somebody refers to 
  43. the deceased menu, right?  If I purge a menu which I'm sure I don't 
  44. need any more, and then am careful not to refer to it again (in 
  45. the MenuBar or otherwise), I should be safe, right?
  46.  
  47. 4.  Looking at my heap, I noticed that my DITL and DLOG resources 
  48. were not being purged, even though the corresponding dialog had 
  49. been dismissed.  Sure enough, IM I-413 says 'GetNewDialog makes a 
  50. copy of the item list and uses that copy.'  Also, 'GetNewDialog 
  51. doesn't release the memory occupied by the resources.'  Well, poofle.  
  52. Am I safe in marking these resources as purgeable in the file?  In 
  53. other words, once these resources have been read in by GetNewDialog, 
  54. could they be purged before GetNewDialog has had a chance to make 
  55. its copy of them?  If this danger exists, does that mean I have to 
  56. mark these resources as not purgeable and then call GetResource
  57. and ReleaseResource for the DITL and DLOG resources 
  58. every time I'm finished with a dialog?  (Please, no flames about
  59. using modal dialogs. :-)
  60.  
  61. 5.  Does there exist any kind of development tool which keeps track 
  62. of how much space is free in your heap, and gives you an average 
  63. and peak amount of how much space is allocated during the whole 
  64. run of your application?  Such a tool would be very useful in 
  65. empirically determining how big the heap needs to be.  As it is now, 
  66. I have to figure out what point of the program is likely to have 
  67. the highest level of allocated memory and set a breakpoint there 
  68. to examine things.  This takes a lot of guesswork and time, and it 
  69. seems like someone somewhere would have written a tool to address 
  70. this problem.  (It would be especially nice if such a tool gave you 
  71. a list of the top ten peaks of memory use, as well as the names of 
  72. the routines where those peaks occurred).  Does anything like this 
  73. exist?
  74.  
  75. Thank you much.
  76.  
  77. --Kurisuto
  78.  
  79.