Instantiating Morphs
Last updated at 3:50 pm UTC on 14 January 2006
Question 19 July 2003,Stephane Ducasse: Why does this cause a walkback? Do-i on:
ColorPickerMorph new openInWorld
Then bring up the halo and select the delete (pink with cross) halo.
Answer How to save a parts bin You need to initialize the ColorPickerMorph more than by just calling new. Look at Morph>>changeColor for a typical usage. (or the Instantiating Morphs Swiki page.)
Question Isn't this a sign that the client interface creation of this class is not really good. Either it should provide a good interface or it should break directly at creation time. Answer Well, "new" isn't (always) the idiom for getting fully-usable Morphs. And there are some morphs that aren't really usable by themselves, though one could wire them up for testing.
If you look at the return value of #includeInNewMorphMenu you will see whether a particular class doesn't want to be instantiated from that menu. Also, the classes in 'Morphic-Menus' and 'Morphic-Support' don't show up in that list.
I'd argue that #newStandAlone should work for all Morph classes that could conceivably be instantiated by themselves. Which leaves the question open of how to mark or otherwise handle classes that can't do this.
We have (in addition to #new):
- #wantsToBeOpenedInWorld (open in world vs. in hand from New Morph menu)
- #installModelIn: (called by some clients but not others)
- #initializedInstance (called by the "sample instance" menu choice)
- #newStandAlone (which is called by #initializedInstance if it's defined) (which then calls #initializeToStandAlone)
- #authoringPrototype (which is called when a Morph is put in a flap)
- #descriptionForPartsBin and #supplementaryPartsDescriptions (used for the Objects tool)