Kay C. L. wrote: > Moving right along, for those Slack Moders, if you run the same statements: > > repeat with x=1 to 20 > do "local tVar_" & x > do "put x*x into tVar_" & x > end repeat > put tVar_5 into msg --not hidden in <do> > > For reasons I do NOT understand, you get a runtime error: > > line: do "local tVar_" & x > hint: local tVar_5 > > If you remove/comment the line: do "local tVar_" & x > > everything will then run fine - reinforcing your decision to choose Slack > Mode because declaring vars is so 3GL ;-) > > So long story short; contrary to the example, it would seem to be > counter-productive to use <local> within a <do> statement.
Hi, I read about "do" again last night, because Craig N. (in a comment to Peter H.'s QCC #16941) suggested to use single quotes also for triggering a re-compilation, as "do" does. He used a 'declaration'-example similar to yours. Now you end in a rather nifty example. on mouseUp repeat with x=1 to 20 do "local tVar_" & x do "put x*x into tVar_" & x end repeat put tVar_5 into fld 2 end mouseUp [1] In strict compilation mode it throws "unquoted literal" on "tVar_5", all OK. [2] In slack compilation mode it throws "local tVar_5", also OK? I think so. The point is: *** "do" recompiles ***. Thus line 3 with x=5, what is "local tVar_5", is offending in that re-compilation, because tVar_5 is already implicitly declared in line 6 of first compilation. > .. It may be be counter-productive to use <local> within a <do> statement I would like to add to your advice the following line. 'This may help sometimes: Read "do" as if it were on the end of current handler.' ======= Hermann _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode