I was diagnosing a game bug and came across this behavior, which seems like a bug to me.
BrightScript Debugger> a = ["red", "blue"]
BrightScript Debugger> ? a
red
blue
BrightScript Debugger> for each col in a: ? "color " col: end for
color red
color blue
BrightScript Debugger> for each col in a: ? "color " col: ? "test " a: end for
color red
test red
blue
BrightScript Debugger>
The FOR EACH loop breaks! It never does blue!
Why would printing a break the larger loop? Why does iterating through a to print it break the overall iteration of a for the FOR EACH loop? Is that a bug or is that common/known behavior across many programming languages?
“Komag” wrote:
I was diagnosing a game bug and came across this behavior, which seems like a bug to me.
BrightScript Debugger> a = ["red", "blue"]
BrightScript Debugger> ? a
red
blue
BrightScript Debugger> for each col in a: ? "color " col: end for
color red
color blue
BrightScript Debugger> for each col in a: ? "color " col: ? "test " a: end for
color red
test red
blue
BrightScript Debugger>
The FOR EACH loop breaks! It never does blue!
Why would printing a break the larger loop? Why does iterating through a to print it break the overall iteration of a for the FOR EACH loop? Is that a bug or is that common/known behavior across many programming languages?
You’re probably confusing the counter by referencing the array that way.
This code achieves the desired result -
Function Main()
a=["red","blue"]
for each col in a
print "color " col
end for
for each col in a
print "color" col
end for
for each col in a
print "test" col
end for
End Function
Produces this output -
color red
color blue
colorred
colorblue
testred
testblue
Yes. Currently each enumerable object has a single iteration pointer associated with it.
So if within a ‘for each’ loop you nest another ‘for each’ loop, directly call the object’s ifEnum functions Reset or Next, print the object (which internally iterates over the object), or similarly call FormatJSON, it will affect the outer iterator.