>David and Dragan,
>
>I've used the SCATTER NAME when building a list of record to be moved to some where else;
>
>

>LOCAL laRecs(1), loObj
>lnCnt = 1
>SCAN FOR Some Condition
>  DIMENSION laRecs(lnCnt)
>  SCATTER MEMO NAME loObj
>  laRecs(lnCnt ) = loObj
>  lnCnt = lnCnt + 1
>ENDSCAN
>* Now laRecs has one row for each record that is a scatter name object that can * be used in a gather name operation
>
>

Hey, this seems like object copying - I mean, you scatter to loObj every time, and assign it to laRecs(lnCnt), and then scatter to it again - and the array still keeps the old values. In all the situations we've had so far (AFAIK) assigning an object variable to another variable has created an object reference, and not a new copy of the object.

Now this may be the logic behind it, if I'm right: an object variable is actually a pointer to a memory structure holding the PEM block (non-default properties and, say, a pointer to a block with class code and default properties). Assigning an object to another variable creates just another pointer to the same block. Destroying the variable doesn't necessarily destroy the block, so the copy keeps the reference to it. Well, well... this sheds some light on the matters, if I'm right. Furthermore, the corollary is that the block is aware of all the references to it, else it wouldn't so stubbornly refuse to be released if there's an outstanding reference. This leads to another nice FoxWish - could, please, objects be so kind to reveal all the references to themselves? A method which will return list of variables referencing it, comma delimited...