In my (Squeak) project I modified PluggableTextMorph >> getText to be as follows: getText "Retrieve the current model text" | newText | getTextSelector isNil ifTrue: [^Text new]. newText := (getTextSelector numArgs = 1) ifTrue: [model perform: getTextSelector with: self] ifFalse: [model perform: getTextSelector]. newText ifNil: [^Text new]. ^newText shallowCopy The change allows the getTextSelector to pass an additional argument: self. I made this change because I wanted to know which PluggableTextMorph was asking for text. This is useful when one has large numbers of similar PluggableTextMorphs. Note that the method PluggableTextMorph >> acceptTextInModel already does this so I didn't need to modify it. Thus I think my change makes PluggableTextMorph more consistent. Any chance of this change being made a part of the Pharo image? Frankly, I would prefer that all the GUI objects that have get/set messages had this capability. For CheckBoxes I earlier added the capability to return either self or some arguments (by subclassing this time). I am happy with the result. Another way I could do this would be to create a holder for the PluggableTextMorph (or other gui object) that would respond to the getText and acceptTextInModel messages and would know which PluggableTextMorph is speaking to it (since there would be only one). The holder would replace the model in the PluggableTextMorph and have a reference to the original model to which it could forward messages. Again this would allow me to have a large number of similar PluggableTextMorphs. One could create a PluggableTextMorphHolder class for this or create a single holder class that could work with different Morph classes (only one at a timeof course) (by responding to messages from all of them). It would be nice of course if these GUI holders already existed in Squeak/Pharo so I didn't have to invent them. Which approach do you think is better? Regards, Ralph Boland -- I've been middle class and I've been poor. Middle class is better.