home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / programm / 12840 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.6 KB  |  62 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!mips!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!quads!jcav
  3. From: jcav@quads.uchicago.edu (JohnC)
  4. Subject: Re: Question: memory allocation in OpenPic()
  5. Message-ID: <1992Jul22.155456.3054@midway.uchicago.edu>
  6. Sender: news@uchinews.uchicago.edu (News System)
  7. Reply-To: jcav@midway.uchicago.edu
  8. Organization: The Royal Society for Putting Things on Top of Other Things
  9. References: <1992Jul22.063600.12458@midway.uchicago.edu>
  10. Date: Wed, 22 Jul 1992 15:54:56 GMT
  11. Lines: 49
  12.  
  13. In article <1992Jul22.063600.12458@midway.uchicago.edu> blis@midway.uchicago.edu writes:
  14. >If I might indulge upon the patience of the fair readership of 
  15. >comp.sys.mac.programmer, it would be to ask about OpenPic(), whose
  16. >full discription I do not know, as neither I or the nearest bookstores
  17. >has IM I.  
  18. >
  19. >pascal PicHandle OpenPicture(const Rect *picFrame)
  20. >presumably sets the picSize element of the PicHandle based on 
  21.                      ^^^^^^^
  22. The picSize field contains (for historic reasons) the low-order word of the
  23. 32-bit byte count of the picture data.  You shouldn't use it anymore, but
  24. should instead call _GetHandleSize on the picture handle.  You should also be
  25. aware that the size of the picture data bears little relation to the picFrame
  26. rectangle.
  27.  
  28. >picFrame, but by what formula and what scale? I ask because it is
  29. >not clear to me how OpenPicture() allocates the appropriate memory
  30. >for the PicHandle, and what this appropriate amount would be.  
  31.  
  32. Between your _OpenPicture and _ClosePicture calls, all (well, most)
  33. Quickdraw calls are recorded into the picture, like a tape recorder.  As
  34. each call is made, new data is added to the end of the picture, and the
  35. handle size increases as needed, a little (or a lot) at a time.
  36.  
  37. >I naively hoped that something like
  38. >Rect        myRet;
  39. >PicHandle    picture;
  40. >
  41. >myRec.left=0;
  42. >myRec.right=500;
  43. >myRec.top=0;
  44. >myRec.bottom=300;
  45. >picture=OpenPicture(&myRec);
  46. > /*bunch of MoveTo, LineTo, etc..*/
  47. >ClosePicture();
  48. >
  49. >would work, but apparently I was wrong.  This code seems to work
  50. >if I create an application instead of running from inside TC.
  51. >Have I done something stupid in configuring TC? Or have
  52. >I instead done something stupid in the code.
  53.  
  54. Your code seems just fine.  Could you be more specific as to what is going
  55. wrong?
  56.  
  57. -- 
  58. John Cavallino                  |  EMail: jcav@midway.uchicago.edu
  59. University of Chicago Hospitals |         John_Cavallino@uchfm.bsd.uchicago.edu
  60. Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
  61. B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637
  62.