[Squeakland] "add a parameter" script feature in etoys
Dreyfuss Pierre-André (EDU)
pierre-andre.dreyfuss at edu.ge.ch
Wed Nov 7 03:52:34 PST 2007
you'll find two examples, polygon and tree, at:
Note that handling recursion will often hang squeak. Use alt/dot keys to stop an infinite loop.
player's Variables should only used as constants, they are not local variables.
I'll try to use a container as heap to simulate local variables.
-------- Message d'origine--------
De: squeakland-bounces at squeakland.org de la part de Bill Kerr
Date: mer. 07/11/2007 03:13
À: Scott Wallace
Cc: squeakland org mailing list
Objet : Re: [Squeakland] "add a parameter" script feature in etoys
thanks for reply
when I download your pr file I get this message:
"Reading an instance of MorphExtensionPlus, which modern class should it
What should I do, I'd like to see your demo
On Nov 7, 2007 11:55 AM, Scott Wallace <scott.wallace at squeakland.org> wrote:
> On Nov 1, 2007, at 3:50 PM, Bill Kerr wrote:
> > I can't assign a variable to the "add a parameter" feature available
> > through the scripts menu in etoys. The parameter type is displayed
> > and the type can be altered but it doesn't go green when I try to
> > replace it with a variable of the right type. I can drag off a tile
> > for the parameter type but that doesn't seem to help.
> Hi, Bill,
> I'm not sure I understand exactly what you're asking, but perhaps a
> few general words about script parameters, and a simple example, will
> be helpful...
> The "Tile for the parameter type" that you can drag from the header of
> a Scriptor is actually a tile representing the parameter value
> itself. You can drop such a tile at any type-appropriate place within
> the body of the script. Thus, if the parameter type is "color", the
> tile will be labeled "Color", and can be dropped on any Color-type
> tile in the script, and if the parameter type is "number", the tile
> will be labeled "Number" and can be dropped on any Number-type tile in
> the script, etc.
> I attach a small example which illustrates use of a script parameter.
> The script that has a parameter is called "wobble", and it takes a
> numeric-valued parameter. Its role is to make the object turn by a
> random amount within the limit specified by the parameter. The larger
> the value of the parameter, the wider will be the variance. Notice
> that in the body of the script, there are two places where a "Number"
> tile, representing the value of the numeric parameter, is used. Both
> of these "Number" tiles were obtained by dragging them from the
> "number" tile in parameter area in the header, then dropping them on
> numeric-valued tiles:
> A typical use of such a script can be seen in the two other scripts in
> the example, one called "wideWobble", which calls "wobble" with a
> parameter value of 70 (degrees), which makes for fairly wild random
> wobble, and the other called "narrowWobble", which calls "wobble" with
> a parameter value of 20 degrees, which makes for much less erratic
> Here's the script for "narrowWobble":
> You can experiment with the behavior of these two scripts by holding
> down the yellow "!" control for one or the other, or by first making
> one of them "ticking", then observing the effect, then stopping that
> script and making the other one tick, etc. Or, for a combined effect
> (fwiw) make them both tick at the same time, perhaps at different
> ticking rates.
> BTW: we have successfully prototyped a much better UI for presenting
> parameters to the user; the new design allows the user to *name* the
> parameter, allows a *default value* for the parameter to be specified
> in the scriptor's header, and (because of now having a default value)
> also allows a script with a paremeter to be set "ticking". But
> unfortunately we haven't had time yet to bring this into the
> mainstream etoys system.
> > I'm trying to make a fractal tree in etoys but need two parameters.
> > Is it possible?
> No, sorry, only one parameter is allowed per script in this version of
> The standard workaround for this is to pass the desired additional
> parameter info in a *variable* which you add to the object for just
> this purpose, and which you set in the caller, and which you "get" in
> script itself. This requires extra bookkeeping by the person writing
> the script, and can cause problems in recursive-call situations, but
> otherwise in practice is quite workable. And, since the data being
> passed reside in visible variables belonging to the object, their
> values can be conveniently observed in Viewers and Watchers, which can
> be quite a good debugging aid.
> -- Scott
More information about the Squeakland