The problem as I understand it is how to propagate messages to tell all outgoing connections from the current object and all sucessors outgoing connetions etc.

See solution below: [image: Inline image 1] Each node is a Sibling and Each Connector is a Sibling. So when I run "hideConnOut" it tells all its "outgoing connections" to hide AND tells all its succesors to do the same.

FYI Siblings are very useful when you want a bunch of objects to have the same behavior. They share scripts and variables (ie: if you create a variable in one sibling they all have that script, but one could be running and the other not. Same with variables add one and they all Siblings have that variable (but they can have different values). Below is from the Etoys reference manual:

About Siblings (by Karl)

If you hold down shift while copying with the green halo handle you make a copy. http://booki.flossmanuals.net/etoys-reference-manual/_full/

Almost... What you now have are two *sibling players*, each of which is a "Player" or "Object" in its own right. (Also copies made by the Player Copy tile are siblings.) Each players wears its own separate Morph as its costume. The siblings are related in that they share certain things in common, in particular: scripts and variable definitions. So if you add a variable to one sibling, all siblings will have their own instance of that variable with the same name. The same name, but the values can be different. For example if I add a variable called "speed" to one sibling, all siblings will have a variable with that name. But I can have one sibling with speed=5 and another with speed=10. Same variable name different values.http://booki.flossmanuals.net/etoys-reference-manual/_full/

Also if I add a script to one sibling, all siblings will have the same script (and same scripting tiles, if I change it in any sibling at anytime). But although siblings share a script, each sibling has its own private "status" for that script, i.e.remembers separately whether the script *as used by this instance* is "normal", "paused,", or "ticking", or set to trigger on mouse-up, etc.; and what the tick-rate is.http://booki.flossmanuals.net/etoys-reference-manual/_full/

When using siblings, what's really happening underneath is that there is a custom Player "Class" is created to bear the shared code, and the siblings are individual "Instances" of that class. "Class" and "Instance" are among the most fundamental concepts of object-oriented programming http://booki.flossmanuals.net/etoys-reference-manual/_full/

So why would you use siblings? Well besides teaching one of the most fundamental concepts of object oriented programming, you could use siblings in a game to make characters that have similar behaviors (aka scripts) but different looks (you can change the looks by either re-drawing the sketch or by setting the http://booki.flossmanuals.net/etoys-reference-manual/_full/Sketch's graphic (if the object is a Sketch or image you copied in) or changing its size and colors. You could also have ships in a game that keep track of how many times they were hit (using a variable to count the # of hits). That way you can program a basic ship once and make multiple siblings. Then if you decide to change the behavior (ex: modify a script, or add a new variable), you can change it once and all the siblings are changed.

Siblings could also be used to try to simulate or model real world behavior. For example deer population or some other animal. You could create an Object that simulates the behavior of a deer: searches for food, ages, breeds (at a certain age), etc. and make sibling copies of that one object. Then each Sibling (aka individual instance of the Class Deer which you have defined) could age, search for food (and find it or not which could affect its life expectancy), etc at its own rate. You could also create predators and food that grows. Then run multiple simulations varying the amount of food, starting number of dear, # of predators, etc.

If the "all instances" box is not checked in AllPlayers, you'll see the scripts for only one player of each sibling group. This will give you "control" over the scripts of only one of the players. If you want to be able to "control" scripts for both of the siblings, make sure the "all

instances" checkbox is checked. Unless the "all instances" checkbox is checked, creation of new siblings will typically not result in any noticeable change in the all- scripts tool, since all the scripts of the new sibling will already be represented by another instance in the tool. Perhaps that's what you're seeing.

Also, if the "tickers only" box is checked, only scripts whose status is "ticking" or "paused' are shown in the all-scripts tool. This can be another reason why the all-scripts tool may seem not to be "picking up" on a change.

On Sat, Sep 14, 2013 at 4:45 PM, Lawson English lenglish5@cox.net wrote:

I'll try again:

I have 19 Connectors nodes showing in my project.

There are 19 x 18 connectors -a fully connected graph.

I want to be able to easily tell all connectors to hide using Etoys scripting. I already know how to do this with Squeak, but it isn't obvious at all how to make it work with etoys, despite the existence of a scripting option "tellAllIncomingConnections" and "tellAllOutgoingConnections"

I can't figure it out.

I've dropped down into the System browser and looked at the Smalltalk code for

#tellAllIncomingConnections: aMessageSelector

and

#tellAllOutgoingConnections: aMessageSelector

"Send the given message selector to all the players of the receiver's

costume's outgoing connections"

self costume outgoingConnections do:
    [:m |
        m playerRepresented ifNotNilDo:
            [:p | p performScriptIfCan: aMessageSelector]]

I've even tried putting ^#hide into the script.

Is this aspect of Connectors + Etoys broken or am I missing something?

I can specify a SPECIFIC Connector to hide, but I have potentially 19 x 18 or even 256 x 255 of them to work with, so obviously this isn't an option.

Do I have to go with my incredibly cumbersome code I worked out in my Squeak youtube tutorials and stick that into a script, instead?

Thanks.

L

-- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/**playlist?list=**PL6601A198DF14788D&feature=** view_allhttps://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan

______________________________**_________________ squeakland mailing list squeakland@squeakland.org http://lists.squeakland.org/**mailman/listinfo/squeaklandhttp://lists.squeakland.org/mailman/listinfo/squeakland