Re: dynamic text fields, how-to...

[Mats Leidö]

Hi again. The text member creation is now implemented into the movie, 
and it wasn´t that much of a pain actually. Did you know the member 
number of the first cast member in castlib 2 is 131073? Just try out 
this in the message window (if you have two casts in your movie)
put member(member 1 of castlib 2).number
 Hehe...

I am bringing this thread up again because I would like to reply to a 
couple of side comments on the subject from Daniel Nelson and Tony 
Bray. I did find them interesting, I just couldn´t find the time to 
answer them right away. Sorry about that. Charlie Fiskeaux, Sean 
Wilson and Carl West have other interesting side comments which I 
would like to reply to also - in the next email.

Diego Landro wrote:
 > Isn´t it annoying when you find out that something is not working
 corretly just when you are deep inside coding and have done most of it,
 and it is just (at least in this case) from some malicious glitch in
 > Director.
Daniel Nelson replied:
This is not a glitch.  It is very beneficial to be able to access 
and control the text of a field or text member without knowing what 
sprite it is in.  If each sprite used the same member, you'd have to 
hard code sprite references to gain access over those text members, 
which would
be miserable software development practice.
Mats Leidö wrote:
 > U bet it is - it really would be nice to use text in a field/text
 > sprite as a property variable for the sprite. But, when in Rome...
Daniel Nelson replied:
Again, I disagree.  How would you find that sprite without hard 
coding its sprite number?
If the handler that changes the text is in a behaviour attached to 
the sprite that wouldn´t be a problem, right? You would be able to 
refer to the sprite by using the spritenum property or 
sprite(me.spritenum). Then the default text could also be typed in a 
getPropertyDescriptionList dialog box field. If communicating with 
the sprite from outside the sprite number could instead be added to a 
global sprite reference list variable or just a simple global 
variable.

If we are still imagining the scenario of dynamically created 
sprites, you would almost always need to keep track of those 
"dynamic" sprites with a linear list or a property list anyway, 
perhaps residing in a sprite creator object, to be able to reference 
them in an easy way. So I don´t quite see how this would be a 
problem? To me it would only be good news.

Tony Bray wrote:
This is exactly the same for text, shapes, bitmaps, etc.
...
The written text is the contents of the text cast member, just as 
the red ball is the contents of the bitmap cast member.
...
A sprite is an instance of a cast member. Alter the cast member and 
all instances will change to reflect that alteration.
You are absolutely right about the text being a member property, and 
that changing a member property always changes all instances of that 
member on stage. However, there actually are several sprite 
properties that change the appearance of a sprite. Some examples are: 
color, forecolor/bgcolor, ink and blend, quad, rotation and skew for 
bitmaps.
I imagine it would be possible for Macromedia to implement a dynamic 
text cast member type where the displayed text is a property variable 
of the sprite, not just a member property - maybe the field members 
could sport a sprite.text property in the next version of Director? I 
for one would like that.
[To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi  To post messages to the list, email [EMAIL PROTECTED]  (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo.  Thanks!]