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
Thanks for the contributions, Charlie and Sean!
Charlie Fiskeaux II wrote:
Members can be deleted dynamically during runtime, with member(x).erase().
As another point, you can specify the member to be used when you create a
new member, if you use
new(#text, member(1, 3))
where 1 is the
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
On Wednesday, Sep 3, 2003, at 09:29 Pacific/Auckland, Mats Leidö wrote
(in part):
Another approach is to use a #flash member to display text. You can
use a flash member with a text field in it and change its text and
it won't affect the member. So you can use the same flash member for
many
However,
there are potential performance hits using lots of flash sprites on
the same frame.
Why do you think you have the performance hit? It is because everytime you
use a Flash Member as a sprite, you are in fact invoking another
instance of the Flash player (flash xtra).
Yes, and each
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 6:06 PM
Subject: Re: lingo-l dynamic text fields, how-to...
Charlie Fiskeaux II wrote:
Members can be deleted dynamically during runtime, with
member(x).erase().
From the docs:
For best results, use this command
that
keeping track of texts is easier with one way objects.
- Original Message -
From: Daniel Nelson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 5:37 PM
Subject: Re: lingo-l dynamic text fields, how-to...
Isn´t it annoying when you find out that something
On Thursday, Aug 28, 2003, at 09:21 Pacific/Auckland, Diego Landro
[EMAIL PROTECTED] wrote:
The problem with text (or fields for that matter) members is that
you can´t change the text within the sprite without affecting the
member
itself. It does not work for text or fields as it does for
open to suggestions - I´m not even sure how I would go about creating
text members on-the-fly. Thankful for any input
Dynamically creating members in cast castlib name:
new(#field, castLib(castlib name))
new(#text, castLib(castlib name))
Regards,
Daniel
[To remove yourself from this list,
Of. 100
Tel. 4812-9979/7398
(1955) Ciudad de Buenos Aires - Argentina
-Mensaje original-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] En nombre de Daniel Nelson
Enviado el: Miércoles, 27 de Agosto de 2003 12:07 p.m.
Para: [EMAIL PROTECTED]
Asunto: Re: lingo-l dynamic text fields, how
Is there any other way of making it work besides creating multiple text
cast members and assigning each sprite its own cast member? I am open to
suggestions - I´m not even sure how I would go about creating text members
on-the-fly.
Daniel showed you how to create members on the fly.
Another
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.
This is not a glitch. It is very beneficial to be able to access and
If you create an instance of the text (i.e. sprite) and you change that
instance, you will change the original member of the cast, no matter
what. That´s why you´re having this problem.
Exactly. Annoying, in a way.
On the other hand, having three color properties, each one with a
different color
Thank you, Daniel and Carl!
Maybe it isn´t all that bad creating the members. Or maybe I am
better off using bitmap images and positioning them on stage...
naaahh.
I think I´ll try creating members inside a repeat loop. By the by,
creating members dynamically will take some little time, won´t
Dynamic member generation is fast enough. No need for asymmetry here.
One note: create the dynamic members in a cast devoted to dynamic members. Then,
during authoring, you can simply delete all the members in that cast without worrying
about deleting other members.
Note: Members cannot be
nuisance. At least until one figures out how they work. I learnt
today that the forecolor property updates as you change the color
property - only, the color can be an rgb value, and the forecolor is
a color number (not a paletteIndex, as the bgcolor is. Oh my god.
Then, when you change the
Subject: Re: lingo-l dynamic text fields, how-to...
Dynamic member generation is fast enough. No need for asymmetry here.
One note: create the dynamic members in a cast devoted to dynamic
members. Then, during authoring, you can simply delete all the members in
that cast without worrying about
Charlie Fiskeaux II wrote:
Members can be deleted dynamically during runtime, with member(x).erase().
From the docs:
For best results, use this command during authoring and not in projectors, which can
cause memory problems.
Regards,
Daniel
[To remove yourself from this list, or to change
I don't believe it's asymmetric. I'm pretty sure it happens as
fast as you can tell it to.
The code I gave you makes 100 members per second on my G3
Just creating them it's more like 500 per second.
yeah, well I was thinking of also putting them on stage, using
puppetsprite and assigning each
19 matches
Mail list logo
