Ok, you got me. I was considering only a situation of treating them the same way. I wasn't even thinking of Do...With. I don't use Do...With all that much myself. On the other hand, I guess most of my 'functions' are generally object methods anyway.

Alan

>Ah, Alan, but I said "called as" (procs or functions), and there is no way to get a return value from a function (or procedure) called as a procedure (i.e. with DO ... WITH).
>
>Also, at least according to ONE piece of the Help (under SET UDFPARMS):By default, variables are passed to a user-defined function by value. (Variables passed to procedures with DO ... WITH are passed by reference.
>
>
>cheers
>
>>Return values are allowed from procs. Whether it was different in VFP5 or not, I don't recall. Also, as far as I know, both default to parameters passed by value.
>>
>>Alan
>>
>>>I would say no.
>>>
>>>Whether coded as a Procedure or a Function, either can be called as a procedure or a function. Called as a procedure, no return value is expected/obtainable, whereas called as a function you can get a value back.
>>>
>>>So the difference is in the calling and that has other implications as far as how parameters are passed IN (by value or by reference as default, changeable in how the actual call parameters are coded.
>>>
>>>one opinion.
>>>
>>>
>>> >I've been updating an olepublic class that is used in a web server environment. The current version is in VFP5 and is an .exe server. We are evaluating whether it would be faster and more efficient to upgrade the program to VFP8 and create the server as an in-process dll.
>>>>
>>>>Anyway, I've noticed that in the foxweb samples that they use procedures for the methods, and the program I am updating uses functions. Since the samples provided with VFP tend to point you to the "right" way of doing something, should I convert my functions into procedures?