Then in the list procedure I could put inline script as above, e.g.,
myDisplay.x = myDisplay.x + 1
myDisplay.y = myDisplay.y + 1
myDisplay.run
Alternatively, I could put a display object
(myDisplay in our example) directly into the
procedure right after the script, and set its
Duration to 0 (so that the loop simply runs as
fast as it can). Now the display object shows up
directly in the structure instead of staying
hidden in the script, and the script simplifies to
myDisplay.x = myDisplay.x + 1
myDisplay.y = myDisplay.y + 1
This is actually rather clean and elegant,
although I rather prefer not to manipulate
properties directly in script and instead use
attribute references. So, I could use attribute
references in the Postition X and Y properties of
the display object or sub-object, e.g., [myX] and
[myY]. I might also create global variables in
the User Area to hold values for myX and myY
between loop iterations, and as before advance
the position in script before the display object,
and my script might come out like
myX = myX + 1
myY = myY + 1
c.SetAttrib "myX", myX
c.SetAttrib "myY", myY
(Note that although the variables myX and myY
have the same names as the context attributes
"myX" and "myY", these are all distinct objects!)
Admittedly this may seem more troublesome than
using the direct property manipulation as above,
so you have to use your judgment according to the
particular circumstances. And of course, some
time before my List I would have to initialize
myX and myY, but you would have to do that for any of these approaches.
One final issue on using a List to do the loop
instead of Do... While -- by default the List
will create a line in the .edat log for every
loop, which could get messy. You could prevent
that by opening up the Properties dialog for the
list procedure (Edit > Properties... after
selecting the procedure, or right-click anywhere
in the procedure window) and then unchecking Log
Data. Admittedly this is a very obscure feature
and will likely confound anyone who later works
with your program, so perhaps that is reason
enough to stick with the Do... While approach.
-- David McFarlane, Professional Faultfinder