At 8:40 AM -0800 11/17/98, Dan Shafer wrote:

>I have a PasteUpMorph which has within it some buttons (RectangleMorphs
>with embedded and locked editable text) and a single "label"
>(StringMorph). I want the act of clicking on a button to change the
>value (contents) of the StringMorph. I gave the StringMorph a new
>instance variable called "value" and I've browsed the StringMorph and
>determined that it has a method called contents: which should be used to
>set its value but what I can't for the life of me figure out is how to
>reference the StringMorph.

You can't (yet) do this directly using just tile scripts, but if you wish to edit your script textually, you need to be aware that in scripts, "self" is always a *player* and that all references to other objects are to other *players*;  if you want to talk directly to a Morph, you get at it by sending the message "costume" to its associated player.  

That's probably the lone missing piece of information you need to complete your example.

For completeness, I tried out two different ways to implement your example, and they both worked fine:


Suppose your button is named myButton and that it has one submorph inside it, namely that StringMorph, which you've named myLabel.  Suppose further that the Player associated with your button has a string-valued instance variable named 'value' that you've already defined.

Then you could create a script for myButton, and tell it to be triggered on mouseUp, and name-and-save it.  Now proceed to use either of the following two alternative techniques...


Technique One:

Make the script be "textually edited" and edit its script to say just

     self costume submorphs first contents: value

(That'll do it.  self is the player.  "self costume" is the rectangleMorph; its first submorph is the label morph.  value is the player's own string-valued instance variable defined by you, and #contents: sets the contents and does the change notification.)


Technique Two:

>From the viewer of myLabel, drag a phrase -- any phrase, let's say "myLabel forward by 5", into the scriptor for your new myButton script.  The point of this is just so that you can see how to refer to the myLabel guy in the script of the myButton guy, if you don't want to use the "submorphs first" circumlocution of technique one.

Having dragged such a phrase into the scriptor for your button script, now "edit it textually".  You'll see in the textual version something like
     self class refPlayer3 forward: 5
The point of this is that it indicates that "self class refPlayer3" is the way the reference to the label player is encoded.

Using this knowledge, now you can edit the script so that it reads, instead,

    self class refPlayer3 costume contents: value

Unlike the first technique, this one does not rely on the label being the first submorph of the button -- or indeed on its being a submorph of it at all.


Down the road -- hopefully not too *far* down the road -- we want to have a smoother way that you can transition from the point-and-click, drag-and-drop immediacy of the tile-scripting to the full power of smalltalk scripting without the awkwardnesses required in the above two examples.

------

> ...But I do notice that it has an instance variable called contents
> which contains its displayed value. If I edit this value in an
> inspector and accept the change, though, the displayed value of the
> StringMorph doesn't change. (That didn't particularly _surprise_ me
> but it kept me in my quandary.)

This is just a matter of change notification not taking place when you smash a new value into an instance variable in an Inspector.  If, in that same Inspector, after you've submitted a new value for the StringMorph's contents, you evaluate "self changed", you'll immediately see the StringMorph change as you were expecting.  This will not a problem programatically, because you'd send a message like "aStringMorph contents: 'xxx'", and StringMorph's #contents: method issues the change notification.

------

>While I'm at it, how, if at all, can I take a custom morph and put it
>into a Parts Bin so that I can later instantiate it anew? Or has morphic
>proceeded that far yet?

Yes, it's altogether possible (that's the point of the "custom parts bin") but in 2.2 it's still rather awkward to do -- among other things, you have first to tell the parts-bin-page in question to stop being a parts-bin-page, then add the thing you want, then tell it to resume being a parts-bin-page, etc.  In 2.3, coming out soon now, it will be very much more straightforward to add any objects to a parts bin, so I suggest you wait for that.


 -- Scott