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

2003-09-02 Thread 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!]


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

2003-09-02 Thread Mats Leidö
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 membernum and 3 is the castlibnum (you can use a castlib
name, too); then you'll know which member number it is and in which cast it
is.
I wondered if that was possible. Thanks, great info!

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 sprites to display different text on the same frame. However, 
there are potential performance hits using lots of flash sprites on 
the same frame.
See, there we have it! The dynamic flash text member. I will not be 
using flash text in this movie because we will sometimes have lots of 
text sprites on stage, but nevertheless it is an interesting 
alternative.
[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!]


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

2003-09-02 Thread Daniel Nelson


 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!]


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

2003-09-02 Thread Tony Bray
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 sprites to display different text on the same frame. 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).
Each flash xtra is displaying the text field, but each instance is 
unaware of the other instance. Therefore altering the text in one 
instance will not affect the other instance.
This is not the same as have a sprite being an instance of the text.

If you run two copies of the Notepad. exe and then open the same .txt 
file, changing the text in one copy won't change the text in the other 
copy. Only when you come to save the two copies of the same file will 
you get the change, which will infact reflect the text in the last 
saved copy.

Hope this makes sense ;-)

Tony Bray

I came into this world with nothing.
Fortunately I have got most of it left.
[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!]


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

2003-09-02 Thread Sean Wilson

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 instance uses up available memory as well as time to 
composite and render.

Each flash xtra is displaying the text field, but each instance is 
unaware of the other instance. Therefore altering the text in one 
instance will not affect the other instance.
This is not the same as have a sprite being an instance of the text.
Yep, understood. That's why I suggested using #flash text as an option.

Quoting from the horse's mouth:
http://www.macromedia.com/support/director/ts/documents/flash_tips.htm
QUOTE
When using Flash Sprites in Director, each Flash Sprite creates a new 
instance of the Flash Asset Xtra. This means that as more Flash Sprites are 
used, more memory is required by the application and exponentially 
increases the computations required. Developers have reported performance 
difficulties with over twenty simultaneous Flash sprites, which is to be 
expected.
/QUOTE
Included in the above document are some tips for optimisation which are 
well worth looking over.

-Sean. 

[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!]


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

2003-08-28 Thread Charlie Fiskeaux II
That's exactly what I was talking about earlier.  Erasing members at runtime
leaves their memory unclaimable, so you get bloated files.

Charlie Fiskeaux II
Media Designer
The Creative Group
www.cre8tivegroup.com
859/858-9054x29
cell: 859/608-9194

- Original Message - 
From: Daniel Nelson [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 during authoring and not in
projectors, which can cause memory problems.

 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!]


[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!]


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

2003-08-28 Thread Diego Landro
Well, thinking of it that way you are right, maybe it´s not a lgitch after
all, ok, but you must aree that is very annoying whrn you want four texts
onscreen and just have to creae four different members just to put a text
beside a picture or something like that, but youre right when you say 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 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
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.

 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!]

[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!]


RE: lingo-l dynamic text fields, how-to...

2003-08-28 Thread Tony Bray
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 shapes. With
shapes you can create different sprites (instances of the original
object if you´re familiar with OOP), but it is no good with text.
This is exactly the same for text, shapes, bitmaps, etc.
If you put several copies of a text cast member on the stage i.e. 
create several sprites as intances of the same cast member, changes to 
the contents (text) of the cast member will be reflected in all 
instances (sprites) of that cast member.
  If you create a red ball in the paint window, create several 
instances of the red ball as sprites on the stage and then edit the red 
ball in the paint window, all intances (sprites) of the paint cast 
member will change to reflect the edit.
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.
This is the same in Flash -- create an instance from a symbol and then 
change the symbol. All instances will change.



Tony Bray
I came into this world with nothing.
Fortunately I have still got most of it left.
[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!]


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

2003-08-27 Thread Daniel Nelson

 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, 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!]


RE: lingo-l dynamic text fields, how-to...

2003-08-27 Thread Diego Landro
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 shapes. With
shapes you can create different sprites (instances of the original
object if you´re familiar with OOP), but it is no good with text. 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. The only solution is the
one Daniel talked about. Sorry, but it seems youll have to rewrite quite
a lot of code.
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.

 

Diego Landro
Viamonte 1646 7º 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-to...


 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, 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!]

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 14/08/2003
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 14/08/2003
 

[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!]


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

2003-08-27 Thread Sean Wilson

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 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 sprites to 
display different text on the same frame. However, there are potential 
performance hits using lots of flash sprites on the same frame.

HTH,
-Sean. 

[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!]


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

2003-08-27 Thread Daniel Nelson

 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 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.

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!]


RE: lingo-l dynamic text fields, how-to...

2003-08-27 Thread Mats Leidö
 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 description format, for every sprite is also a 
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 color property it won´t change the actual 
color of a bitmap cast member, only add to it. Thus, you can´t make a 
yellow bitmap black by changing its color property w Lingo... But a 
black one can become yellow... It´s fun though, every day something 
new.

The only solution is the
one Daniel talked about. Sorry, but it seems youll have to rewrite quite
a lot of code.
Probably - although this time I hope to be able to sidestep 
somewhat... If I find any solution of interest, I´ll post it here.


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.
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...

Yours tubily
/MoL
[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!]


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

2003-08-27 Thread Mats Leidö
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 it? 
Meaning it would be an assymetrical thingie, a bit like 
downLoadNetThing and the like? Of course, it will probably be faster 
than a file download, but it won´t be instant, right? Would that mean 
I will need to let the playback head move and check every exitFrame 
or so, or maybe check it with a timeout object?

Daniel wrote:
new(#field, castLib(castlib name))
new(#text, castLib(castlib name))
Carl wrote:
This works for me in 8.5 Mac:
bar = new(#text)
put bar
-- (member 2 of castLib 1)
bar.name = Membername
bar.text = Some Content
bar.font = Arial
bar.fontsize = 40
[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!]


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

2003-08-27 Thread Daniel Nelson
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 dynamically deleted during runtime.  As long as you don't 
save the cast in projector mode, they won't build up over time.

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!]


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

2003-08-27 Thread Daniel Nelson

 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 color property it won´t change the actual
 color of a bitmap cast member, only add to it. Thus, you can´t make a
 yellow bitmap black by changing its color property w Lingo... But a
 black one can become yellow... It´s fun though, every day something
 new.

Some of this is outdated, only included for backwards compatibility.



 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...

Again, I disagree.  How would you find that sprite without hard coding its sprite 
number?

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!]


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

2003-08-27 Thread Charlie Fiskeaux II
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 membernum and 3 is the castlibnum (you can use a castlib
name, too); then you'll know which member number it is and in which cast it
is.

Charlie Fiskeaux II
Media Designer
The Creative Group
www.cre8tivegroup.com
859/858-9054x29
cell: 859/608-9194

- Original Message - 
From: Daniel Nelson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 5:08 PM
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 deleting other members.

 Note:  Members cannot be dynamically deleted during runtime.  As long as
you don't save the cast in projector mode, they won't build up over time.

 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!]


[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!]


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

2003-08-27 Thread Daniel Nelson


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 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!]


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

2003-08-27 Thread Mats Leidö
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 sprite its own member. This is were I 
was worried of upsetting Director. So I tried it with the script 
below, triggered by a simple button.
It was fast enough, I think. Between 900-1300 milliseconds for 
creating 100 members and positioning them on stage. I am on OS X and 
trying this out in the browser (as a .dcr file). And no protesting 
from Director when puppeting sprites right after creating the text 
members. This will do nicely, methinks. And methanks!

---
on createManyTextMembers
  stopwatch_start=the milliseconds
  repeat with i= 2 to 101
   
newmem=new(#text, castLib(2))
newmem.text=string(i-1)
newmem.fontSize=9
--create sprites from 11 and upwards
puppetSprite i+10, 1
sprite(i+10).member=member(newmem.member.number)
--never mind the loc, it looks ugly, I just want Director to 
draw to the stage.
sprite(i+10).loc=point(i*10, 10)
  end repeat
  --compare forcing Dir to redraw the stage before putting the alert up and
  --stopping the timer, and not doing that - by commenting out the 
updatestage command.
  updatestage

  stopwatch_stop=the milliseconds
  alert total time:  stopwatch_stop-stopwatch_start  
milliseconds  RETURN \
started at  stopwatch_start  RETURN \
stopped at  stopwatch_stop
end
--

[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!]