I want to use squeak /etoys mainly for exploring

> and visualizing some ideas in a quick way.

>

> Right now I want to build a prototype for an experiment and think that

> this is a good project to learn a bit more about squeak.

>

> I want to program a sequence of objects appearing on different positions

> on the screen one after the other and later in a random order.

> A very dirty way to do so is just script doing something like.

> object1 show.

> script wait for 1000ms.

> object1 hide

> object2 show

> script wait for 1000ms.

>

> I know that this is a very basic question but couldn't find the answer,

> as I don't know what it is I am looking for.

Hi Martin,

Because of the structure of Etoys, entire scripts are done all the way

through (or not at all).

A useful idiom (even in Etoys) for this kind of event-driven behavior

might be the idea of a "state machine".

Note that in Etoys you can "clone" an object that has scripts; all the

clones of an object (its "siblings") will share the same scripts but

have their own copies of variables (and of course their own position,

appearance, etc.). So if you have a number of objects whose behavior is

similar this can be a powerful way to save work (and to have a single

place to change the behavior of all the "sibllng" objects).

The attached image is an example of a very simple state machine that

provides the kinds of delays that would work in your application

(provided you write your program correctly, of course!). The bottom two

scripts (turnRed and turnGreen) would be user-specific and would be

different in your application; the upper ones are generic state machine

infrastructure. You'd change the name of the state in "initial" to the

first state you wanted to run. The state machine shown changes the color

of the ellipse from red to green and back, staying at a particular color

for 2 ticks (you can change the tick rate of the "stateMachine" script

to change the resolution of "delayForTicks:").

This structure provides the ability to change states (note that the

current state script will be invoked every tick) and to delay between

state transitions.

The trick is this: each of these state scripts only get run once per

cycle. They set the delay timer to delay the execution of the *next*

state, then do their thing.

See if you can use this idea for your needs, and tell us what you come

up with!

Enjoy,

--

Ned Konz

ned@bike-nomad.com

I suppose I should add to my prior state machine email that:

• You can move the delayForTicks: lines down to the bottom of the

turnRed and turnGreen scripts; they will make more sense here (as they

really affect the delay after the script runs).

• The stateTest object has the following variables:

- delay, a Number

- currentState, a ScriptName

• the stateMachine script is set to fire once per tick, and you can

change the tick rate to whatever you want. If you change the tick rate

to something other than 1 second, you might want to add a scaling factor

to the delayForTicks: script, and rename it as delayForSeconds: or

delayForMilliseconds: instead.

For instance, if you change the stateMachine script to tick at 10/second

(I think the default is 8/second) you might do this for delayForSeconds:

delayForSeconds: {Number}

stateTest's delay <- Number * 10

So now you can say

stateTest delayForSeconds: 0.3

and have it work as expected.

BTW: to change the tick rate, you hold your mouse down for at least a

second on the little clock face on the script editor. You don't want to

change the "fires per tick"!.