Martin Bleichner wrote:
Hi together,
I am new to this list. So perhaps I should introduce myself. I am 25 year old german student studying congitive neuroscience in Utrecht/Netherlands. 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,