Hi Stephane,

On Mon, 21 Aug 2000 17:57:24 +0200 (MET DST) Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
>Question 1: How to forbid halos

If what you mean is you don't want a particular morph to have halos when cmd-clicked, then implement

wantsHaloFromClick
	^ false

for that morph, but be careful as that may make it harder to debug or delete that morph.

>Question 2: How to delete a morph definitively

The notion of "deleting" a morph is one that often causes some confusion. In the Morphic world, #delete simply means that the receiver is to be disconnected from its owner (the receiver is removed from its owner's <submorphs> collection and the receiver's <owner> is set to nil). The first effect of this action is that the morph is no longer drawn when its former owner is redrawn. Thus the morph visually disappears from the world. The second effect is, *usually*, that the morph will soon be garbage collected. I say *usually* since garbage collection is based on removing objects that are no longer references and the owner of a morph is *usually* the sole referencekeeping the morph alive. So what are the exceptions?

- the trash can. If your preferences are set to put morphs deleted with the pink halo in the trash (so you can get them back if you realize you've made a mistake), then the trash can will be keeping them alive. You can see what's there from World/authoring tools.../view trash contents. You can also empty the trash by a similar menu path. Finaly, you can change your preferences so that things are not put into the trash: World/help/preferences/morphic/ then set "preserveTrash" to false.
- DependentsFields. Sometimes one morph is made dependent on another and for many morphs this means using the DependentsFields dictionary to store the dependency. If the dependency is not explicitly broken, then the morphs in question will not be garbage collected. Inspect DependentsFields to see if your morphs are listed there.
- Some other reference you have created. If you store a morph in a class variable, for example, that morph will not be garbage collected. A common example of this is wanting no more than one copy of a give morph at a time. You might create a class variable to remember when you create one so you don't create a second one. The problem would occur if you failed to clear the class variable when you deleted the morph.

>Then I saw abandon but I got the same result then browsing I found the
>following code.  I have the impression that the method is intended for
>subclasses. But I was expected that Morph>>delete and Morph>>abandon
>would be different or at least that one of the two really delete
>cleanly the morph.

#abandon is indeed intended for subclasses to add additional behavior that they need. In some cases that might include your notion of "cleanly deleting the morph". What would probably help you is to step away from the notion of cleanly deleting anything and ask instead why that object is still around. One way is to evaluate

	PointerFinder on: MyMorph allInstances first

another is to use the menu in the insepctor to find references to the inspected object (note: this can involved many levels and false trails before finding the real reason).

>Question 3 More a remark. I was thinking that delete just remove the morph
>from the world, and was wondering what is the opposite action that could bring
>the morph in the world. I tried openInWorld and it works but I was thinking
>that the protocol could be more symmetric.

The symmetry is missing, I suppose, because #delete works in all cases to break the owner<->submorph relationship. Adding something to the world, on the other hand, has a huge number of possibilities: which existing morph you wish to be the owner of the new morph and where (first, last, other..) the new morph should be positioned relative to any existing submorphs of the new owner.

>Question 4 How to invoke a full gc
>(in VisualWorks MemoryObject verboseGC)

Smalltalk garbageCollect.

>Question 5 Is caseOf: really used?

It doesn't appear to be used in the image, but perhaps some folks use it in private fileins.

>Question 6 Finding the owner of an object

Well, "owner" may have a couple of meanings.

In Morphic, every morph has an owner (which could be nil). Just inspect the morph and look at the owner slot. Or just inapect "myMorph owner".

If you mean "all objects referencing this object", see my answer to #2.

Cheers,
Bob