[squeak-dev] PluggableTextMorph >> getText

Ralph Boland rpboland at gmail.com
Mon Jan 11 19:08:52 UTC 2010


In my 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 Squeak 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 time
of course)
(by responding to messages from all of 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.



More information about the Squeak-dev mailing list