Path: utzoo!attcan!uunet!lll-winken!ames!zodiac!anders@penguin
From: anders@penguin (Anders Wallgren)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problem with MacApp ".Clone"
Message-ID: <11035@zodiac.ADS.COM>
Date: 27 Feb 90 17:24:06 GMT
References: <1990Feb26.185646.21302@mathrt0.math.chalmers.se>
Sender: news@zodiac.ADS.COM
Reply-To: anders@penguin (Anders Wallgren)
Organization: Verity
Lines: 48
In-reply-to: d6caps@dtek.chalmers.se

In article <1990Feb26.185646.21302@mathrt0.math.chalmers.se>, d6caps@dtek writes:
>Problem examples:
>
>1)  Cloning a TView doesn't clone the subviews.
>
>2)  is what made me discover this.  I cloned TCluster and got the
>    same text in both after changing one. Freeing also gave some
>    serious errors. It seemed the fDataHandle wasn't duplicated.
>
>
>So, what?
>
>Am I supposed to change all MacApp-classes and create the Clone method
>myself? (Mucho work :-( )
>
>
>Per Bergland  
>d6caps@dtek.chalmers.se


While the behavior of ::Clone (or .Clone if you prefer...) may not
seem to be logical, at least it's documented:

MacApp 2.0 Globals, page 2:

"TObject.Clone:

"Purpose: To clone dependent objects referred to by the fields of an
object as well as cloning the object itself.  An object is dependent
on another object when the second object has the only (or the only
important) reference to the first object.  Dependency is a relatively
vague condition; when you override this method, you need to determine
what objects are dependent on SELF.

"The default version: Calls ShallowClone, and thus clones only the
object itself"

---

Thus, it's no wonder that you're getting the behavior you described -
Clone is just cloning the references to other objects, not the other
objects themselves - when you modify an object through a reference
field, you're also modifying it for all the clones.  You will probably
need to implement your own Clone method to Do The Right Thing.  This
seems silly, but it can be argued that this is the correct behavior,
given the description above.

anders