Hi, Offray,

> We are also stuck on how to make copies on an eToy, so we work only on

> one, defining scripts, and animations and the we put the amount we

> want

> in the game. We know about the green halo button for copy, but we

> would

> like to use not graphically but from inside of a script. We have tried

> to use the message eToyName's copy but it can't be dragged on a

> script.

> The animations defined for the first eToy are not copied when we

> copy it.

When you execute "Car's copy", the result will be the creation of a

copy of Car (strictly speaking a "sibling", viz. a fellow instance of

the same class as Car.)

However, if you don't *place* that copy somewhere, you won't see it.

The standard idiom for placing an object somewhere via script is to

tell the *container* in which you place it to "include" it.

Here's a typical usage pattern:

Url : http://squeakland.org/pipermail/squeakland/attachments/20061110/b0812a88/unknown.png

> Pdt: It seems that we're reaching some kind of stress point of the

> eToys. Would be nice to have the possibility to go from them to their

> code, but the scripts of the eToys seem to have only a code view,

> but is

> not usable for writing new code.

Hmm, well, etoy objects are first-class Smalltalk objects, and etoy

scripts are real, first-class Smalltalk methods, belonging to real,

first-class Smalltalk classes, and if you switch any script's

Scriptor to textual mode (by clicking on the checkbox in the

Scriptor's header,) you can enter any Smalltalk code you wish there.

A plausible practice is to use tile scripting for everything in a

project that *can* be readily done using tile scripts, then to

supplement this with conventional Smalltalk code in one or two places

where necessary.

Textual coding can actually be done using two kinds of scripts:

First, as mentioned above, you can write textual code for any

existing "etoy script" that you see in a Viewer by switching its

Scriptor to textual mode via the checkbox.

Secondly and this is not so well known you can open a conventional

Smalltalk browser on the class of an etoy "object", and using that

Browser you can not only see and edit the etoy scripts, you can also

add any other methods you wish, including methods with multiple

arguments (whereas etoy scripts are limited to 0 or 1 argument,) mid-

method returns, and many other things that you can't directly obtain

using tiles alone. To get such a Browser, in the Viewer's menu

choose "more..." and from the auxiliary menu that pops up, choose

"browse class."

I'm not claiming that this is the ideal way to transition from e-toy

tile-scripting to full-scale Smalltalk, if that's what your goal is

-- indeed, it may lead to false expectations; I just wanted to make

sure you're aware of the availability of these two ways of blending

tile-scripting with writing unrestricted Smalltalk code. It would be

interesting to hear of experiences people have had with this kind of

hybrid approach.

Cheers,

-- Scott

Once you have typed in textual code for a script, you cannot return

to tile mode without losing the textual code you typed. There is no

automatic translation from user-entered textual code back into etoy

tiles. Indeed, the constructs supported by etoy tiles represent but

a tiny fraction of what can be expressed in textual Smalltalk code.

Some people are quite disappointed, and even offended, when they

first learn this brutal fact. But "etoys" is a tile-scripting

system, with severe and intentional limits to vocabulary, sentence

structure, expression structure, and control structures. The textual-

scripting alternative provides nothing more than a "keyhole" which

allows some people to "escape" from tiles, into textual Smalltalk

programming, specifically to program things that cannot be expressed

with tiles.

Because reverting from a textually-entered script back to tiles is

destructive, the user is presented with a warning if he tries to do

it -- a stern warning that any code he has manually entered via the

keyboard for this script will be lost.

The reason why this warning was not presented when you tried to click

the text/tiles checkbox of the #chooseMessageTarget script to revert

to tiles is because of a bug that appears when you attempt to toggle

a textually-coded script which has never had any non-empty tile

code. (I have a fix for that bug, which I'm about to publish to the

Squeakland alpha update stream.)

However, even if had been allowed, you would not have wanted to

revert that script to its last-known tile form, because in so doing

you would have lost the textual code which is the whole point of the

script.