1. No need to change PROCEDURE to FUNCTION. You can call either one as a function.
2. Yes, that's correct

Be sure to read wOOdy's comments on my blog post.

>Thanks to both of you for the blogs (Craig's is at http://www.craigberntson.com/blog/2009/04/functions-and-procedures-in-vfp-101.asp)
>
>A few follow-ups to be sure I am solid on this...
>
>1. (True or False?)
>If I understand correctly, I could indeed do a complete search-and-replace in my .prg procedure files and rename all FUNCTION statements to PROCEDURE, and/or vice-versa, and my code that calls these will still work *EXACTLY* the same? Since the calling code (call as a function vs. call as a procedure) is what determines whether the params are getting passed by-value or by-ref.
>
>2. (True or False?)
>A Procedure definition can indeed have a Return statement in it, but whether a value is actually returned or not is determined on how the Proc is called. Call it as a Func to get the return value, or call as a Proc syntax, and you will no get the return value.
>
>
>
>
>
>>It mostly comes down to personal preferences unless you need a return value which only UDF call can return. I prefer to use UDF calls. See Difference between FUNCTION and PROCEDURE statements for more info.
>>
>>>I have several procedures in a .prg file that I call in various places in my form methods. And, I have "Set Procedure to WhatEver additive" in my app startup routine.
>>>
>>>So, when I want to use one of the procedures from a form or class method, I usually do something like this:
>>>
>>>

>>>Do SomeProcedure with lcSomeCharString1, lcSomeCharString, llSomeBoolValue
>>>

>>>
>>>I like the look of my code better if I do this:
>>>
>>>

>>>SomeProcedure(lcSomeCharString1, lcSomeCharString, llSomeBoolValue)
>>>

>>>
>>>It seems to work either way, so, are there any pros or cons to one way over another?
>>>
>>>.