>>I think I've found the problem. Do you invke the procedure with DO...WITH...? Passing a PUBLIC by REFERENCE (the default) results in the PUBLIC being hidden. the following code snippet demonstrates this nicely:
>>
>>

>>PUBLIC cTest
>>cTest = 'ByRef'
>>DO MyFunc WITH cTest
>>ctest = 'ByVal'
>>=MyFunc(cTest)
>>CANCEL
>>
>>PROCEDURE MyFunc
>>LPARAMETER uVar
>>? uVar
>>? 'The type of the parameter is',TYPE('uVar')
>>? 'The type of the PUBLIC cTest is',TYPE('cTest')
>>RETURN
>>

>>
>>You can force a pass by value by invoking the procedure as a function, or by enclosing the argument to the WITH in parentheses to force a pass by value. This behavior of PUBLICs passed by reference is actually documented somewhere...
>
>
>Hi,
>
>The above is quite true when you you send parameters by reference, but I send the parameters by value (SET UDFPARMS TO VALUE) and that's why it troubles me. The phenomena also occurs regardless of me using LPARAMETERS or PARAMETERS in the procedure.
>

It's been a while since i looked, but as i recall, SET UDFPARMS only applies when invoking a procedure as a FUNCTION, not via DO...WITH. My reading of the documentation in VFP 6 under remarks is that DO...WITH always passes by reference: A quote from the docs:

Remarks

By default, variables are passed to a user-defined procedure by value. (Variables passed to procedures with DO ... WITH are passed by reference.)

italics added by me. The gist of the doc is that there is a clear distinction made in the behavior of a UDF and a procedure, and SET UDFPARMS appears to only apply to invocation of UDFs. That follows the behavior I see. An array passed to a procedure by DO...WITH is always by reference, and there's no way to override the behavior of DO...WITH to force pass by reference (in a function, you can force by reference by prefixing with @; this construct is not available to DO...WITH). There is a means of overriding to pass by value by enclosing the argument in parentheses, so that the argument is treated as an expression and the result of the expression is passed.

I realize that may not be how you'd like it, but there's an easy fix here - just force the pass by value in DO...WITH by enclosing in parentheses. If you need to pass by reference to get returns from side-effects, then don't use a PUBLIC; hopefully, you can see the problems that would be created if the same chunk of data could be altered by two different name references (VFP uses a type of indirection, where there's a table of names of things that point to value references; if the variable is updated, the value reference can be replaced by a different one in the name table. If one reference were changed, how would you know to update the other variable reference's value pointer, so that things would't get very confused very quickly.

Ed