[Squeakland] Fwd: misc: elementNumber, obj id

[Scott Wallace]

Hi, Randy,

Here's one way to approach this kind of thing...

Add a new variable to your object, name it (say) "newGuy", and set 
its "value type" to "Player".  You can then use this variable to 
refer to the new copies as you make them, and using this you can 
*talk* to the new copies, to set them up with whatever 
characteristics you prefer.

Thus, in your example, the "variables" pane in a Viewer would look 
something like:

   

Now in your script to make a copy and add it to the playfield, do 
something like this:

   


You'll find the idNumber of the first copy you make will be 2; the 
next one will have idNumber 3, and so forth, just as desired.


Cheers,

   -- Scott


At 2:57 PM -0500 10/5/05, Randy Heiland wrote:
>Thanks Scott.  OK, so let's say I create an "idNum" variable for my object,
>P1.  What I'd then like to do is, using a script, create siblings of P1
>*and* assign unique values to each sibling's idNum, e.g. assign sequentially
>increasing integers:
>  P1->idNum = 1
>  P2->idNum = 2
>...
>
>I know that I can create siblings in a script via:
>  Playfield include: P1 copy
>
>But how can I then assign a value to the new sibling's idNum variable?
>I tried:
>  P1's copy idNum <- p1's copy elementNumber
>
>But of course each "P1's copy" actually instantiates new siblings.
>
>Hope this makes sense, and thanks,
>--Randy
>
>>  -----Original Message-----
>>  From: Scott Wallace [mailto:scott.wallace at squeakland.org]
>>  Sent: Wednesday, September 28, 2005 8:33 PM
>>  To: heiland at indiana.edu
>>  Cc: squeakland at squeakland.org
>>  Subject: Re: Fwd: [Squeakland] misc: elementNumber, obj id
>>
>>  Hi, Randy.
>>
>>  Yes, the elementNumber of an object in a container will change as the
>>  order of objects in the container changes, and the order depends on
>>  the order in which the objects were added to the container... and
>>  when you "pick up" an object and then drop it back into a container,
>>  that counts as being freshly added to the container, so the last
>>  object "touched" will be the one with the largest elementNumber.  So,
>>  in short, you can't count on elementNumber to stay the same unless
>>  you're not "touching" the objects.
>>
>>  So what to do instead?  I'd recommend that you maintain your *own*
>>  "idNumber" variable in the objects in question, and give each of the
>>  objects its own unique  value for an idNumber... and use *those* in
>>  your reckonings instead of "elementNumber."  Since this is a variable
>>  that you have created and assigned values to yourself, its value is
>>  not going to change unless you proactively change it, so you should
>>  be able to use it to distinguish reliably among siblings.
>>
>>  Cheers,
>>
>>     -- Scott
>>
>>  PS:  If the above isn't clear, please send a concrete example and we
>>  can work it through together.
>  >
>  >
>  > >>From: "Randy Heiland" <heiland at indiana.edu>
>  > >>To: <squeakland at squeakland.org>
>  > >>Date: Wed, 28 Sep 2005 11:16:28 -0500
>  > >>
>  > >>Can someone tell me a bit more about this tile in the miscellaneous
>  > >>category?  Its balloon help says "my index in my container".  I'm simply
>  > >>experimenting with some siblings in a playfield, seeing if I can have
>>  >>sibling-dependent behavior based on each sibling's
>  > identifier/elementNumber.
>  > >>It seems that whenever I grab one of the siblings and move it, its
>  > >>elementNumber changes.  I'd like some fixed identifier assoc'd with each
>  > >>sibling.
>  > >>
>  > >>--Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://squeakland.org/pipermail/squeakland/attachments/20051005/3b44fa98/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: P0A538744_4
Type: image/png
Size: 26252 bytes
Desc: not available
Url : http://squeakland.org/pipermail/squeakland/attachments/20051005/3b44fa98/P0A538744_4-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: P0A538744_5
Type: image/png
Size: 51649 bytes
Desc: not available
Url : http://squeakland.org/pipermail/squeakland/attachments/20051005/3b44fa98/P0A538744_5-0001.png