Squeak
  links to this page:    
View this PageEdit this Page (locked)Uploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
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 part 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):