Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!information-systems.east-anglia.ac.uk!jrk
From: jrk@information-systems.east-anglia.ac.uk (Richard Kennaway CMP RA)
Newsgroups: comp.sys.mac.programmer
Subject: GetScrap
Message-ID: <14620.9010311321@s4.sys.uea.ac.uk>
Date: 31 Oct 90 13:21:16 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 27

According to IM, GetScrap will automatically resize the handle you give it
as its first argument so as to be large enough to hold the scrap data, and
behave sensibly (i.e. not crash) if it cant get the memory.  However, I've
found that the latter is true, but not the former.  When GetScrap
successfully resizes the handle I give it, I sometimes dont get the
correct data in it.  It's as if at some point the handle got moved,
without its data being copied to the new location.  This has only happened
when the data was larger than 32k, though whether that's a coincidence I
dont know.

I've worked around this by always first calling GetScrap with a nil
handle, to find out the size, then making a handle that size and passing
it to a second call of GetScrap.

Is this a bug?  I havent seen this behaviour described anywhere.  If
the above work-around is necessary, then the example code in IM1 p.460
is wrong, but GetScrap isnt even indexed in IM4 or the latest index to
the TNs.

I'm using MPW C 3.0, if it matters.
--
Richard Kennaway          SYS, University of East Anglia, Norwich, U.K.
Internet:  jrk@sys.uea.ac.uk		uucp:  ...mcvax!ukc!uea-sys!jrk

NB. Due to local difficulties, I'm posting by a nonstandard route.  The
addresses in the .sig are definitive, I dont know what the header is
going to look like.