I remember from school that when we called a function, it had to return to to the statement just after the "call". And, it had to return a value. I liked functions in the earlier xBase tools cause i didn't have to code a "DO". I could just line out the call (like a C call). At some point, VFP allowed me to call a proc just like a function. I liked procedures because they didn't have to return to the line after the call, they could spaghetti their way through the code, and did not need to satisfy the line after the call.

In VFP 5, as I remember, if the function called was added to the form with the add method, the call required parantheses "MyForm.AddedFunction()", where as imbedded functions did not "MyForm.Show".

Is there a difference (now) between a PROCEDURE and a FUNCTION? I know that some products use "function pointers" to allow in-line (re) assignments of methods that required a return value: "MyForm.MyButton.OnClick=SomeOtherClickMethod()"

I would be interested in any differences between defining a snippet with FUNCTION as opposed to defining it with PROCEDURE.

It seems you're indicating that the way VFP looks up a snippet name is dependant on the disignation as either a FUNC or a PROC?

Is there a difference - or is the difference important in specific calling environments?



>Below I describe some omissions and some suggested improvements for the "FUNCTION Command" documentation:
>
>1) There is no description/definition of the "parameter1" or "parameter2" parts of the two syntax outlines. I think they deserve some formal reference, if only to state that using the second syntax described causes any parameters to be scoped as LOCALs within the function.
>
>2) The second paragraph under the Parameters FunctionName heading has two problems:
>---a) The statement includes the words: "in these two products". The words "two products", in particular, makes no discernable sense.
>---b) It is not particularly clear. And my simple testing cannot isolate any problem calling functions, even within the same .prg, where one has a 10 character name and another has a name that is longer but uses the same first 10 characters as the first. If it is a problem then should it not also mention:
>--------- i) the effect of the regular VFP search sequence on **this** issue;
>---------ii) any differences pertinent to a single .prg containing many PROCEDURE/FUNCTION entities.
>
>3) It is not indicated how a function can be caused to be executed. There is reference to the DO option (sixth paragraph under Remarks) in the statement: "When you issue DO with a function name, Visual FoxPro searches for the function in a specific order as follows:" but that is all. Personally, I can think of three other ways to cause execution:
>-----a) =MyFunction(parm1, parm2)
>-----b) MyFunction(parm1, parm2)
>-----c) objref.MyFunction(parm1, parm2)
>
>4) Once you address #3 above, then the statement that is a single-line paragraph under item 4 of the search sequence description: "Include the IN clause in DO to execute a function in a specific file" may require additional qualification to state the acceptability (or not) of the IN clause in those usages.
>
>5) The statement immediately after the one referred to above: "By default, parameters are passed to functions by value" is incorrect, most especially in the context of the only "call method" described, which is DO. When a DO is used, parameters are passed by reference unless they are enclosed in parentheses, in which case they are passed by value.
>---a) Of course a statement regarding the treatment of parameters when a 'function call' or a 'method call' (see #3 above) is used is also required.
>
>6) The usage example is probably more confusing than it is helpful, especially since the technique shown to invoke the function is undescribed in all of the write-up (it uses a "method call").
>In addition the example shows usage of the command within a DEFINE CLASS, strongly suggesting that everything described above is all that is necessary/relevant to its usage under a "DEFINE CLASS" statement.
>In addition there is a 'function call' to MESSAGEBOX without notation that it itself is a function call.
>
>7) Would it not be helpful to describe that any FUNCTION commands coded within a DEFINE CLASS/ENDDEFINE actually become "methods" of the coded class, the name becoming the method name (especially given the example)???
>
>I feel that it is unhelpful that the FUNCTION statement is described partially in one place (under "FUNCTION Command") and partially in another place (under "DEFINE CLASS"). While I do not feel that it is necessary to remove the content under "DEFINE CLASS", I do feel strongly that all aspects of any possible FUNCTION statement should be described under the "FUNCTION Command" entry.
>After all, when someone is having a problem and needing to refer to the Command Reference, using the Index option to locate it will not even list the additional variations found under "DEFINE CLASS". As bad, the reader has to get all the way to the bottom of the Remarks section to even have a chance to guess that there is more relevant information inside "DEFINE CLASS".
>Of course it would be necessary and acceptable to state that the relevant clauses are applicable only within "DEFINE CLASS".