You're welcome. <s>

>This is very good info to have. Thank you for sharing it.
>>>Number 3 took me a while. Not to get the answer; I just ran the code. To figure out *why*. Talk about trick questions. <g>
>>>
>>>I don't have the questions at my fingertips. I assume that question 3 is the one that requires you to know what happens when parameters are passed by reference vs being passed by value.
>>
>>Yup, that's the one:
>>
>>

>>LOCAL X
>>X = "Apples"
>>DO Y WITH X
>>
>>FUNCTION Y
>>LPARAMETERS X
>>X = 'Pears'
>>RETURN
>>

>>
>>What's X?
>>
>>I knew the difference between passing by reference and passing by value.
>>
>>What tripped me up was the fact that the DO command calls something that is nominally a function. Help says parameters passed to functions are passed by value, and parameters passed to procedures are passed by reference--unless you change the value of SET("UDFPARMS"). I knew that already, and I also knew that it wasn't fully accurate in some sense, though I wasn't clear on where the discrepancy was.
>>
>>So I kept going back and forth in the Help between LPARAMETERS, PARAMETERS, PRIVATE, LOCAL, SET UDFPARMS, DO... It took me several minutes of hard staring at DO to realize that the operative factor is how the code is called, not how it's defined. With UDFPARMS at its default setting, if you call the thing with DO ... WITH ...., the parameter(s) will be passed by reference whether the thing you call is defined as a function or a procedure. If you call the thing with MyFunction(someparm), then it's passed by value whether MyFunction is defined as:
>>
>>FUNCTION MyFunction(someparm)
>>ENDFUNC
>>
>>or
>>
>>PROCEDURE MyFunction
>> LPARAMETERS someparm
>>ENDPROC
>>
>>or even
>>
>>FUNCTION MyFunction
>> LPARAMETERS someparm
>>ENDFUNC
>>
>>or
>>
>>PROCEDURE MyFunction(someparm)
>>ENDPROC
>>
>>About the only thing that won't work is
>>
>>DO MyFunction() WITH someparm
>>
>>No matter how the code is defined, that throws an error.
>>
>>The deeper I dig, the less I know. <g>