Re: Using 'for each' to modify a container

2006-10-12 Thread Jim Ault
Hello, Jacque,

On 10/11/06 8:14 PM, J. Landman Gay [EMAIL PROTECTED] wrote:

 Bill Marriott wrote:
 
 And I'm *really* concerned about the second part of your report
 
 Further, I don't reuse the name 'thisLine' in the next instance of a
 repeat
 for each loop in the *same handler*, but change the name to avoid
 conflict,
 such as 'thisline', 'thisline1', 'thisLine2'.  Again, unpredictable
 results
 occasionally.
 
 Surely THAT is a definite bug?! Have other people experienced this? Are you
 able to reproduce it? Is there a bug on it already filed? I do this all the
 time and I'd have to update a lot of code to fix it.
 
 For what it's worth, I do it all the time too and have never had a
 problem. I think maybe the original poster was just being cautious.
 
I am the original poster, and I will explain a bit more.  I have several
apps that do some intense data parsing, error checks, and reformatting.   At
some point during the development a few months ago I was trying to chase a
set of bugs in a handler that were very elusive.

My standard repeat form evolved to:

repeat for each line LNN in varList
  put item 1 to 2 of LNN  cr after newVarList
end repeat
delete char -1 of newVarList

and, like you, reused my choice of LNN.  Cool beans.  However...in one long
handler...

Using Variable Watcher and some test variables, I saw 'LNN' change the way
you would expect, then later, strangely, it held some garbage characters,
and thus the bug(s).  The failure was not always the same, but it did fail
before the end of the process.  By not reusing LNN each time, the problem
has not returned.

My current system is to use LNN1, LNN2, LNN3, etc.  The reason I use all
caps is to remind me not to change the variable,
but rather recast ( eg. get LNN) so I could change the value.

You are right about 'just being cautious'.  I have too much to accomplish to
go through the 'strange debug' again.

Jim Ault
Las Vegas



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-12 Thread Mark Smith
Clearly, it shouldn't be necessary, but I wonder if putting empty  
into LNN or delete variable LNN after each loop has finished would  
cure that?


Best,
Mark


On 12 Oct 2006, at 07:51, Jim Ault wrote:


Hello, Jacque,

On 10/11/06 8:14 PM, J. Landman Gay [EMAIL PROTECTED]  
wrote:



Bill Marriott wrote:


And I'm *really* concerned about the second part of your report

Further, I don't reuse the name 'thisLine' in the next instance  
of a

repeat
for each loop in the *same handler*, but change the name to avoid
conflict,
such as 'thisline', 'thisline1', 'thisLine2'.  Again, unpredictable
results
occasionally.


Surely THAT is a definite bug?! Have other people experienced  
this? Are you
able to reproduce it? Is there a bug on it already filed? I do  
this all the

time and I'd have to update a lot of code to fix it.


For what it's worth, I do it all the time too and have never had a
problem. I think maybe the original poster was just being cautious.

I am the original poster, and I will explain a bit more.  I have  
several
apps that do some intense data parsing, error checks, and  
reformatting.   At
some point during the development a few months ago I was trying to  
chase a

set of bugs in a handler that were very elusive.

My standard repeat form evolved to:

repeat for each line LNN in varList
  put item 1 to 2 of LNN  cr after newVarList
end repeat
delete char -1 of newVarList

and, like you, reused my choice of LNN.  Cool beans.  However...in  
one long

handler...

Using Variable Watcher and some test variables, I saw 'LNN' change  
the way
you would expect, then later, strangely, it held some garbage  
characters,
and thus the bug(s).  The failure was not always the same, but it  
did fail
before the end of the process.  By not reusing LNN each time, the  
problem

has not returned.

My current system is to use LNN1, LNN2, LNN3, etc.  The reason I  
use all

caps is to remind me not to change the variable,
but rather recast ( eg. get LNN) so I could change the value.

You are right about 'just being cautious'.  I have too much to  
accomplish to

go through the 'strange debug' again.

Jim Ault
Las Vegas



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-12 Thread Scott Rossi
 Using Variable Watcher and some test variables, I saw 'LNN' change
 the way you would expect, then later, strangely, it held some garbage
 characters, and thus the bug(s).  The failure was not always the same, but it
 did fail before the end of the process.  By not reusing LNN each time, the
 problem has not returned.

FWIW, I ran into a similar issue some time ago: garbage characters randomly
appearing in a variable.  Took me weeks of messing around with complex code
since I couldn't get simple tests to fail.  Eventually I determined the
problem was contrived object references.  I was manually creating object
references like btn 1 of stack coolstack which for some reason was
intermittently failing and being stored as garbage.  Once I started
referencing objects using their long IDs, the problem disappeared.

Chalk this up as another ...might save someone else a few headaches

Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia  Design
-
E: [EMAIL PROTECTED]
W: http://www.tactilemedia.com


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-12 Thread Robert Brenstein


The first part though, about not changing the contents of a loop 
variable, does give unexpected results though I hardly ever get an 
actual script error. Usually I just get scrambled variables.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com



Strange. I do it all the time and never seen a problem. Notably all 
such loops in my programs are really short, no more than a few lines. 
May be I am just lucky that I do not trigger the condition that 
scrambles the content but it might be time to change my habits :)


Robert Brenstein
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-12 Thread Trevor DeVore

On Oct 12, 2006, at 12:03 AM, Mark Smith wrote:

Clearly, it shouldn't be necessary, but I wonder if putting empty  
into LNN or delete variable LNN after each loop has finished  
would cure that?


Putting empty into the labelVariable in each repeat loop solves some  
problems so I would imagine it would in the above as well.  I've done  
this before:


repeat for each line theLine in theData
split theLine by ; AND :
-- do something fancy
put empty into theLine
end repeat

Without the line put empty into theLine the code doesn't always  
work correctly.  With the line it does.  Of course, according to the  
docs I was being bad and should change my behavior.



--
Trevor DeVore
Blue Mango Learning Systems - www.bluemangolearning.com
[EMAIL PROTECTED]


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-12 Thread Robert Sneidar
I have experienced no corruption of data, but I certainly have had  
unexpected behavior. Given:


put 1 into mcnt
repeat for each line tline in mlist
  put empty into word 1 of tline
  put tline into line mcnt of mlist
  put mcnt + 1 into mcnt
end repeat

As each iteration of the repeat loop progresses I find the data I get  
in tline is shifted to the right by the length of the deleted data.
I can only think an index is created at the start of the loop which  
points to a memory location, and since the data is shifting while the  
pointer does not, you must not change the contents of mlist until the  
loop is finished.


So I learned when using this form to either store the contents of  
mlist in a temporary variable and modify that, or build a temporary  
variable as I go until the loop is complete. Then I put the contents  
of that variable into mlist if that's what I want.


I have had no problems changing the contents of tline.

Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM

On Oct 11, 2006, at 5:45 AM, Mark Powell wrote:

I want to use the 'for each' form of the repeat loop, but don't  
know how

to use it to modify data within a container.  For example:

repeat for each line thisLine in vContainer
  put doSomeFunction(item -2 of thisLine) into item -2 of thisLine
  --how do I get the change back into vContainer?
end repeat

Thanks!

Mark Powell
mark_powell (at symbol) symantec.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-12 Thread Richard Gaskin

Robert Sneidar wrote:

put 1 into mcnt
repeat for each line tline in mlist
   put empty into word 1 of tline
   put tline into line mcnt of mlist
   put mcnt + 1 into mcnt
end repeat


FWIW, doing the data collection with the form put...into line... loses 
much of the performance value of using repeat for each, as it requires 
the engine to crawl through mlist looking for mcnt number of CRs each 
time through the loop.


To counter this, some years ago Scott Raney optimized the put...after 
form, so you could have a second variable as a collector for things you 
gather during the iteration, and would probably see a snappy performance 
boost:


  put empty into tNuList
  repeat for each line tline in mlist
 put empty into word 1 of tline
 put tline cr after tNuList
  end repeat


This practice of collecting from one source and concatenating to a 
different destination also takes care of the anomalies you noted when 
attempting to modify the source container within a repeat for each loop.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Using 'for each' to modify a container

2006-10-11 Thread Mark Powell
I want to use the 'for each' form of the repeat loop, but don't know how
to use it to modify data within a container.  For example:

repeat for each line thisLine in vContainer
  put doSomeFunction(item -2 of thisLine) into item -2 of thisLine
  --how do I get the change back into vContainer?
end repeat

Thanks!

Mark Powell
mark_powell (at symbol) symantec.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread Malte Brill

hi Mark,

try this:

repeat for each line thisLine in vContainer
  put thisLine into tLine
  put doSomeFunction(item -2 of thisLine) into item -2 of tLine
  put tLine cr after tContainer
end repeat
delete char -1 of tContainer
put tContainer into vContainer

Hope that helps,

malte
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread Bill Marriott
You shouldn't try to change the tires while the car is moving, and you 
shouldn't try to modify the entity being used as the basis of a repeat loop.

For example, if you were to say

repeat with i = 1 to 20
end repeat

you shouldn't try to modify i within the loop.

If you say

repeat for each line theLine in myVariable
end repeat

you shouldn't try to modify myVariable within the loop.

There are probably many possibilities for your solution, but I would 
probably do it this way:

put empty into newContainer
repeat for each line thisLine in vContainer
  put doSomeFunction(item -2 of thisLine) into item -2 of thisLine
  put thisLine  return after newContainer
end repeat
put char 1 to -2 of newContainer into vContainer

Mark Powell wrote:
  I want to use the 'for each' form of the repeat loop, but don't know how
  to use it to modify data within a container.  For example:

  repeat for each line thisLine in vContainer
put doSomeFunction(item -2 of thisLine) into item -2 of thisLine
--how do I get the change back into vContainer?
  end repeat 



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread Jim Ault


On 10/11/06 6:34 AM, Bill Marriott [EMAIL PROTECTED] wrote:

 You shouldn't try to change the tires while the car is moving, and you
 shouldn't try to modify the entity being used as the basis of a repeat loop.
 
 For example, if you were to say
 
 repeat with i = 1 to 20
 end repeat
 
 you shouldn't try to modify i within the loop.
 
 If you say
 
 repeat for each line theLine in myVariable
 end repeat
 
 you shouldn't try to modify myVariable within the loop.
 
 There are probably many possibilities for your solution, but I would
 probably do it this way:
 
 put empty into newContainer
 repeat for each line thisLine in vContainer
   put doSomeFunction(item -2 of thisLine) into item -2 of thisLine
   put thisLine  return after newContainer
 end repeat
 put char 1 to -2 of newContainer into vContainer

Actually, I try to avoid changing the value returned by the 'for each'
--original version
 put empty into newContainer
 repeat for each line thisLine in vContainer
   put doSomeFunction(item -2 of thisLine) into item -2 of thisLine
   put thisLine  return after newContainer
 end repeat
 put char 1 to -2 of newContainer into vContainer

--my preference is 
 put empty into newContainer
 repeat for each line thisLine in vContainer
   put doSomeFunction(item -2 of thisLine)cr after newContainer
 end repeat
 put char 1 to -2 of newContainer into vContainer

I think the reason that 'for each' is so fast is that it scans the
vContainer memory space, returns those characters, and is not meant to be
modified.  My experience is that it is unpredictable to rely on the changed
value of 'thisLine'

Further, I don't reuse the name 'thisLine' in the next instance of a repeat
for each loop in the *same handler*, but change the name to avoid conflict,
such as 'thisline', 'thisline1', 'thisLine2'.  Again, unpredictable results
occasionally.

Jim Ault
Las Vegas


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread Bill Marriott
Hi Jim,

 I think the reason that 'for each' is so fast is that it scans the
 vContainer memory space, returns those characters, and is not meant to 
 be
 modified.  My experience is that it is unpredictable to rely on the 
 changed
 value of 'thisLine'

Wow, this is very interesting to me. I just checked the documentation 
(2.6.1) on the for each chunkType labelVariable for of repeat, and was 
astonished to find:


Important! You cannot change the labelVariable in a statement inside the 
loop. Doing so will cause a script error. You can change the content of the 
container, but doing so will probably produce unexpected results.


Ya learn something new every day! Sounds kind of cheesy to me, though. Why 
wouldn't it be identical to

repeat with i = 1 to the number of chunkType in theContainer
  put chunkType i of theContainer into labelVariable
  -- do stuff
end repeat

Your explanation is plausible, but if it is so then why permit (You can 
change...) changing the contents of the container itself within the loop? 
That would seem to cause an even bigger problem.

BTW, I set up a button with the following script:

on mouseUp
  put empty into newContainer
  repeat for each line thisLine in fld 1
put thisline  *** into thisLine
put thisLine  return after newContainer
  end repeat
put char 1 to -2 of newContainer into fld 1
end mouseUp

Which not only didn't generate a script error but worked perfectly as 
expected. Is the bug in the documentation, or that it doesn't generate a 
script error, or that for each doesn't let you modify the labelVariable?

And I'm *really* concerned about the second part of your report

 Further, I don't reuse the name 'thisLine' in the next instance of a 
 repeat
 for each loop in the *same handler*, but change the name to avoid 
 conflict,
 such as 'thisline', 'thisline1', 'thisLine2'.  Again, unpredictable 
 results
 occasionally.

Surely THAT is a definite bug?! Have other people experienced this? Are you 
able to reproduce it? Is there a bug on it already filed? I do this all the 
time and I'd have to update a lot of code to fix it.

This would suggest to me that maybe I shouldn't use i more than once in a 
handler as the control variable for a repeat as well (something I always do, 
unless nesting the loops of course).

I won't even get into the idea of declaring the labelVariable as a global!

 --my preference is
 put empty into newContainer
   repeat for each line thisLine in vContainer
   put doSomeFunction(item -2 of thisLine)cr after newContainer
 end repeat
 put char 1 to -2 of newContainer into vContainer 



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread Jim Ault
On 10/11/06 3:05 PM, Bill Marriott [EMAIL PROTECTED] wrote:
 Hi Jim,
 I think the reason that 'for each' is so fast is that it scans the
 vContainer memory space, returns those characters, and is not meant to
 be
 modified.  My experience is that it is unpredictable to rely on the
 changed
 value of 'thisLine'
 
 Wow, this is very interesting to me. I just checked the documentation
 (2.6.1) on the for each chunkType labelVariable for of repeat, and was
 astonished to find:
 
 Important! You cannot change the labelVariable in a statement inside the
 loop. Doing so will cause a script error. You can change the content of the
 container, but doing so will probably produce unexpected results.
 
(disclaimer.. I do not have assembler programming, or other low-level
experience, so what follows in an amateur discussion)

I believe this stems from the way memory registers are managed.  The very
tiny bit of C and Pascal programming I read meant I had to first learn how
to manage anything I created, finally releasing it back to the operating
system.  The penalty was mucho errors and unexpected results.

My guess is that Rev is allowing speed in cases where they do not have to
munger variables in memory, therefore you cannot reliably 'redefine' them on
the fly.  A loop counter may be an offset index that is pre-set when the
loop starts, thus very fast, but not to be changed during execution.  Kinda
like re-indexing a database.

I am ready for those who know the real story to fire away :-)
 
 Ya learn something new every day! Sounds kind of cheesy to me, though. Why
 wouldn't it be identical to
 

 repeat with i = 1 to the number of chunkType in theContainer
   put chunkType i of theContainer into labelVariable
   -- do stuff
 end repeat
The  'to the number of'   useage is much, much slower, thus not identical

 Your explanation is plausible, but if it is so then why permit (You can
 change...) changing the contents of the container itself within the loop?
 That would seem to cause an even bigger problem.
 
 BTW, I set up a button with the following script:
 
 on mouseUp
   put empty into newContainer
   repeat for each line thisLine in fld 1
 put thisline  *** into thisLine
 put thisLine  return after newContainer
   end repeat
 put char 1 to -2 of newContainer into fld 1
 end mouseUp
 
 Which not only didn't generate a script error but worked perfectly as
 expected. Is the bug in the documentation, or that it doesn't generate a
 script error, or that for each doesn't let you modify the labelVariable?
The error probably depends on what other operations are being done in the
memory stack of Rev.  Here 'memory stack' is the area of computer memory
registers the system reserves for Rev to use.   If nothing requires Rev to
'move' memory locations, then your labelVariable will be in the same
location the next time you want to access it.

Its like the coffee cup on your desk.  You reach for it without looking, and
all is well, unless someone pushed it closer to you when you were not
looking.

 And I'm *really* concerned about the second part of your report
 
 Further, I don't reuse the name 'thisLine' in the next instance of a
 repeat
 for each loop in the *same handler*, but change the name to avoid
 conflict,
 such as 'thisline', 'thisline1', 'thisLine2'.  Again, unpredictable
 results
 occasionally.
 
 Surely THAT is a definite bug?! Have other people experienced this? Are you
 able to reproduce it? Is there a bug on it already filed? I do this all the
 time and I'd have to update a lot of code to fix it.
 
 This would suggest to me that maybe I shouldn't use i more than once in a
 handler as the control variable for a repeat as well (something I always do,
 unless nesting the loops of course).
 
 I won't even get into the idea of declaring the labelVariable as a global!
All I can say is that you are getting a tradeoff...
memory registers + speed vs controlled variables and definitions

 --my preference is
 put empty into newContainer
   repeat for each line thisLine in vContainer
   put doSomeFunction(item -2 of thisLine)cr after newContainer
 end repeat
 put char 1 to -2 of newContainer into vContainer 


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread Ken Ray
On 10/11/06 5:05 PM, Bill Marriott [EMAIL PROTECTED] wrote:

 Wow, this is very interesting to me. I just checked the documentation
 (2.6.1) on the for each chunkType labelVariable for of repeat, and was
 astonished to find:
 
 
 Important! You cannot change the labelVariable in a statement inside the
 loop. Doing so will cause a script error. You can change the content of the
 container, but doing so will probably produce unexpected results.
 
 
 Ya learn something new every day! Sounds kind of cheesy to me, though. Why
 wouldn't it be identical to
 
 repeat with i = 1 to the number of chunkType in theContainer
   put chunkType i of theContainer into labelVariable
   -- do stuff
 end repeat

Because in the example you cite above, every time through the loop, Rev has
to count the number of chunkType until it reaches the desired location.
Take a look at this Script C from this tip from a while back for more
info:

  Increasing Script Performance, Part I
  http://www.sonsothunder.com/devres/revolution/tips/scrp005.htm

in fact the other tips in this series are equally important:

  Increasing Script Performance, Part II
  http://www.sonsothunder.com/devres/revolution/tips/scrp006.htm

  Increasing Script Performance, Part III
  http://www.sonsothunder.com/devres/revolution/tips/scrp007.htm

 Your explanation is plausible, but if it is so then why permit (You can
 change...) changing the contents of the container itself within the loop?
 That would seem to cause an even bigger problem.
 
 BTW, I set up a button with the following script:
 
 on mouseUp
   put empty into newContainer
   repeat for each line thisLine in fld 1
 put thisline  *** into thisLine
 put thisLine  return after newContainer
   end repeat
 put char 1 to -2 of newContainer into fld 1
 end mouseUp
 
 Which not only didn't generate a script error but worked perfectly as
 expected. Is the bug in the documentation, or that it doesn't generate a
 script error, or that for each doesn't let you modify the labelVariable?

It's not the loop variable that is problematic to change, it's the
container. So in this:

  repeat for each line tLine in tData

you can manipulate tLine to your hearts content, but not tData. tData has
already been examined, parsed, and put into memory in known places so
iteration through the loop can go lightning fast... if you attempt to change
tData you throw a wrench in the works.

 And I'm *really* concerned about the second part of your report
 
 Further, I don't reuse the name 'thisLine' in the next instance of a
 repeat
 for each loop in the *same handler*, but change the name to avoid
 conflict,
 such as 'thisline', 'thisline1', 'thisLine2'.  Again, unpredictable
 results
 occasionally.

I personally haven't ever encountered this. I have always been able to reuse
the loop variable without problem...

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread J. Landman Gay

Bill Marriott wrote:


And I'm *really* concerned about the second part of your report

Further, I don't reuse the name 'thisLine' in the next instance of a 
repeat
for each loop in the *same handler*, but change the name to avoid 
conflict,
such as 'thisline', 'thisline1', 'thisLine2'.  Again, unpredictable 
results

occasionally.


Surely THAT is a definite bug?! Have other people experienced this? Are you 
able to reproduce it? Is there a bug on it already filed? I do this all the 
time and I'd have to update a lot of code to fix it.


For what it's worth, I do it all the time too and have never had a 
problem. I think maybe the original poster was just being cautious.


The first part though, about not changing the contents of a loop 
variable, does give unexpected results though I hardly ever get an 
actual script error. Usually I just get scrambled variables.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread Bill Marriott
 you can manipulate tLine to your hearts content, but not tData. tData has
 already been examined, parsed, and put into memory in known places so
 iteration through the loop can go lightning fast... if you attempt to 
 change
 tData you throw a wrench in the works.

But Ken, that's exactly what the documentation says is NOT to be done (and 
should generate a script error).

My first post assumed what you said (ok to manipulate tLine, not to 
manipulate tData), but it seems the reality is opposite. Weird, huh? :) 



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread Ken Ray
On 10/11/06 10:21 PM, Bill Marriott [EMAIL PROTECTED] wrote:

 you can manipulate tLine to your hearts content, but not tData. tData has
 already been examined, parsed, and put into memory in known places so
 iteration through the loop can go lightning fast... if you attempt to
 change
 tData you throw a wrench in the works.
 
 But Ken, that's exactly what the documentation says is NOT to be done (and
 should generate a script error).

Wow... haven't gotten any script errors or any scrambled data... oh well, I
guess I'm just lucky...
 
 My first post assumed what you said (ok to manipulate tLine, not to
 manipulate tData), but it seems the reality is opposite. Weird, huh? :)

Actually when I reread the statement:


Important! You cannot change the labelVariable in a statement inside the
loop. Doing so will cause a script error. You can change the content of the
container, but doing so will probably produce unexpected results.


It sounds like you shouldn't maniuplate either...


Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Using 'for each' to modify a container

2006-10-11 Thread Stephen Barncard
Yes! I wouldn't mess around behind rev's back like that- especially 
with 'binaries'.


sqb



It sounds like you shouldn't maniuplate either...

Ken Ray


--
stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution