home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / programm / 12890 < prev    next >
Encoding:
Text File  |  1992-07-22  |  1.6 KB  |  36 lines

  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!decwrl!csus.edu!netcomsv!mork!stever
  3. From: stever@netcom.com (Steve Riggins)
  4. Subject: Re: Q: DrawString only draws 8 characters of my string
  5. Message-ID: <z-gmb!_.stever@netcom.com>
  6. Date: Thu, 23 Jul 92 02:15:08 GMT
  7. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  8. References: <NEERI.92Jul20230142@iis.ethz.ch> <NEERI.92Jul21135202@iis.ethz.ch> <Meessen-220792090830@130.104.58.7>
  9. Lines: 25
  10.  
  11. In article <Meessen-220792090830@130.104.58.7> Meessen@slig.ucl.ac.be (Christophe Meessen) writes:
  12. >
  13. >DrawString is one of the Routines that may move or purge memory. It is
  14. >indeed essential to lock the handle and make shure it's unpurgeable. This
  15. >should be the case if you didn't set the purgeable option in the info box
  16. >of the 'STR ' resource. 
  17. >
  18.  
  19.   We ran into an interesting purgeable problem.  We have a reosurce CSTR which is basically a zero terminated string.  An external command for HyperCard, getStr, does a GetNamedResource, then a DetachResource and returns the handle to HyperCard.
  20.  
  21.   Well...  If the CSTR was purgeable, then the HANDLE is also purgeable, and
  22. a piece of script like:
  23.  
  24.   put GetStr("fooStr") into gFoo
  25.  
  26. where gFoo is a HyperTalk global, gets rather interesting when memory runs low.
  27. The global will suddenly contain garbage, as HyperCard had just kept the handle
  28. I passed to it around.  The handle was purged behind HyperTalk's back and
  29. whammy, things got wierd.
  30.  
  31.  
  32. -- 
  33. Steve Riggins                  Internet: stever@netcom.com
  34. AppleLink:  Voyager.geek       AOL:      RigginsS
  35. CompuServe: 75300,1635         "Can never have enough EMail addresses"
  36.