> > > 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.
Ah, I see. I tend to use text and field members differently. I often use text to gather or display information through some independent object that interacts with multiple fields. The member name allows me to set or gather that information without knowing to which sprite it is associated. I now realize that if the sprite.member.name still held, then as long as only one copy of that field/text member were used on the stage at a time, it could be found by scanning sprite.member.name for all instantiated sprites. This would allow me to accomplish the same thing without requiring behaviors to be attached to all fields while giving you your member independence. > > 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. The properties you mention above are properties that apply to displaying many types of visual data, not just bitmaps or text. That's one of the differences between sprites and members: member properties apply to a particular member type, sprite properties apply to multiple data types. If Director were to be changed to achieve what you have described, it would need to be a feature of text/field instantiation--duplicating rather than linking to the data--instead of altering the definition of sprites. Certainly, as you have noted with Flash members, it could be done; however, for backwards compatibility issues, there would need to be a new property of text/field members. This property would specify whether to duplicate the member when a sprite to which it is attached is instantiated, or to keep it linked to the cast. Regards, Daniel [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!]
