>The other day I came across a scenario where a LOCAL variable when used as a parameter functioned like a PRIVATE variable. To confirm the behavior, I wrote the following test program.
>
>

>LOCAL laString(3,1) AS CHARACTER, lnX AS INTEGER
>
>laString[1] = "A,B,C"
>laString[2] = "D,E,F"
>laString[3] = "G,H,I"
>
>* pass each element of the array to the DisplayMessage function
>FOR lnX = 1 TO 3 STEP 1
>	DisplayMessage( laString[lnX] )
>ENDFOR
>
>RETURN
>
>
>FUNCTION DisplayMessage
>
>	LPARAMETERS tcMessage AS CHARACTER
>	LOCAL lnTotal AS INTEGER, laMessage(1) AS CHARACTER, lnX AS INTEGER
>
>	* split the message into an array
>	lnTotal = ALINES(laMessage, tcMessage, .T., ",")
>
>	* display each part of the passed parameter
>	FOR lnX = 1 TO lnTotal STEP 1
>		?? laMessage[lnX]
>	ENDFOR
>
>ENDFUNC
>

>
>What I expected to see is ABCDEFGHI in the output. What I received was only ABC. During debugging, I determined that the lnX variable in the first portion of the program ended up being passed by reference versus value!
>
>I know that the solution would be to store laString[lnX] to a variable, and then call the DisplayMessage() function using the variable. I'm just sick thinking about all of the potential buggy code I may have out because I assumed that LOCAL always meant LOCAL.
>
>Another interesting fact is that the problem does not happen in VFP8. I tested the above code in both VFP7 SP1 and VFP8 SP1 with "SET UDFPARMS" set to VALUE in both. VFP7 failed, VFP8 produced the expected value of ABCDEFGHI.
>
>Has anybody else experienced a similiar problem or did I miss a bug report?

You're right about this occurring in VFP 7.0, but not it 8. I was able to workaround the problem by placing the LOCAL reference to lnX on a separate line. Apparently, when used with data type declarations in 7.0, the LOCAL keyword is ignored and the variable becomes private. This short circiuts the loop counter. Alternate workaround would be to use different variable names, but that becomes a real PITA.