[futurebasic] Re: [FB] [FB^3] Toolbox HANDANDHAND

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : September 1999 : Group Archive : Group : All Groups

From: "Dr. Stratford" <sstratford@...>
Date: Mon, 20 Sep 1999 12:15:20 -0500
Well, since I brought up the question, here's what I did. First I 
checked to see if HANDANDHAND is used anywhere in any of the files in 
the compiler extensions folder. There were none that I could find, 
except for the TOOLBOX definition in Tlbx Standard.INCL. So I just 
changed it:

old version:
///toolbox fn HandAndHand(long) = long `0x205F,0xA9E4,0xC188
new version:
toolbox fn HandAndHand(long,long) = word `0xA9E4'[Stratford, 9/18/99]

Preliminary tests show it works; if anyone knows why it doesn't, feel 
free to amend my work. I wasn't part of the original beta 
conversation about why HANDANDHAND should be given a non-standard 
definition, but IMHO, put the _standard_ Mac definition in the 
runtime, and give the NONstandard one a different name, please... I 
have no idea how that other one with one argument is supposed to work.

>I, for one, would appreciate some definitive and commented sample code (that
>works!) outlining the proper use of HANDANDHAND and HANDTOHAND in both FBII
>AND FB^3.
>I currently provide the same functionality by using SETHANDLESIZE and
>BLOCKMOVE etc. because I've never been able to figure them out in FBII (let
>alone in FB^3)....

OSErr% = fn HandAndHand(srcHdl&, destHdl&) appends the contents of 
srcHdl& onto the end of destHdl&, modifying destHdl&'s size and 
leaving srcHdl& untouched. It returns an OSErr% of zero if 
successful, -108 if memory is full, -109 if a handle is invalid, and 
-111 if an attempt was made to operate on a free block. HandAndHand 
moves memory so be sure the handles are locked. I use this (FBII) 
function whenever I call it (courtesy of Osamu Shigematsu):

LOCAL FN handNhand(aHndl&,bHndl&)'copies from aHndl& to bHndl&
DIM osErr%
DIM aState%,bState%,aSize%
DIM freemem&

LONG IF aHndl&<>_nil AND bHndl&<>_nil
   aState% = FN HGETSTATE(aHndl&)
   bState% = FN HGETSTATE(bHndl&)
   aSize% = FN GETHANDLESIZE(aHndl&)
   freemem& = MEM(_freeBytes)'amount of free memory in bytes
   LONG IF freemem& - aSize% > _kMemDangerLevel
     osErr% = FN HLOCK(aHndl&)
     osErr% = FN HLOCK(bHndl&)
     osErr% = FN HANDANDHAND(aHndl&,bHndl&)
     LONG IF osErr% = _noErr
       osErr% = FN HSETSTATE(bHndl&,bState%)
       bHndl& = FN disposeh(bHndl&)
     END IF
     osErr% = FN HSETSTATE(aHndl&,aState%)
     'we're nearly out of memory so don't move the data
     gMemLow% = _zTrue
END FN = bHndl&

This fn is called like this: destHdl& = fn handNhand(srcHdl&, 
destHdl&). If the HANDANDHAND operation fails destHdl& is returned as 
a _nil handle. Plus I built in a memory check: if memory is low, it 
leaves everything untouched. If the operation is successful both 
handles are left in the same lock/unlocked state. Works for me. It 
could easily be modified to return OSErr% and leave destHdl& 
untouched if that suits you.

I don't use HandToHand for anything. The notion of putting one handle 
in and getting another out goes against the grain...


>It would appear from the traffic that I'm not the only confused one out
>Michael Evans
>Manager of Software Development * Photo Systems, Inc.
>3301 Wood Valley Road, NW * Atlanta, GA, 30327-1515
>Voice: (404) 846-9386
>Fax: (404) 240-0878 * Cell: (404) 229-3930
>E-mail: evans@... * michael_evans@...
>To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>