The only thing that I can add is that since VFP is such a loosely cast langauge, any object of any type could be passed to your function. When specific properties are named this of course can cause errors, especially in a global function of the type described. I usually check for the existence and type of the property:

FUNC IncrementValue
LPARAMETERS oObject
IF VARTYPE(oObject.nmyproperty)#"N"
(Raise or return error condition)
ELSE
oObject.nmyproperty=oObject.nmyproperty+1
ENDIF
RETURN

In your case, since you are passing the property name as well, it would be something like this:

FUNC IncrementValue
LPARAMETERS oObject,cPropertyName
IF VARTYPE(oObject.&cPropertyName)#"N"
(Raise or return error condition)
ELSE
oObject.&cPropertyName=oObject.&cPropertyName+1
ENDIF
RETURN

While this isn't absolutely necssary, I think it helps greatly when debugging and preventing errors in stateless utility-type objects.

Other languages (like Java) are more strongly cast and throw exceptions when an object is not of the type expected. As well you can cast objects of one type to objects of another type when possible and appropriate.

One of the disadvantages/advantages of VFP, depending on the scenario...

Curious for your input, David.

>Thanks, David.
>
>The main reason I am considering sending the property names to the functions is because the library will be re-usable. It's a set of routines for automating the creation of Excel spreadsheets, and I want the routines to be flexible enough that they would not need to know which property names are being referenced.
>
>For example, in my SubTotal function, it relies on an array which contains the row numbers of all the subtotals, which is updated by the function. This array is later referenced by the GrandTotal function. Since the array is part of an object, I figured I would send both the object and property name. This way, I don't need to be concerned with being exactly consistent with naming conventions in my calling procedures.
>
>I wanted to make sure my method was not too weird. Thanks a lot for your opinion!
>
>Michael
>
>
>>What you've done certainly works. Generally it's ok for Visitor objects (oApp in your case) to "know" about the internals of the object they are visiting/manipulating. So it can just:
>>
>>oApp.TestObj( oVar )
>>
>>...
>>procedure TestObj( oVar )
>>oVar.nVar = oVar.nVar + 1
>>endproc
>>...
>>
>>>I would like to pass objects and properties to library functions that will manipulate the values, and want to know the best or "right" way to do it.
>>>
>>>Here's one way I came up with:
>>>
>>>

>>>oApp = CREATEOBJECT("testproc")
>>>oVar = CREATEOBJECT("testobj")
>>>
>>>oApp.TestObj(oVar, "nVar")
>>>? oVar.nVar
>>>
>>>DEFINE CLASS TestProc AS CUSTOM
>>>	PROCEDURE TestObj
>>>	PARAMETERS oObj1, cVar
>>>	oObj1.&cVar = oObj1.&cVar + 1
>>>ENDDEFINE
>>>
>>>DEFINE CLASS TestObj AS CUSTOM
>>>	nVar = 0
>>>ENDDEFINE
>>>

>>>
>>>The TestObj procedure in the TestProc class simply increments the property in the passed object. The object is passed as-is, and the property is passed as a character string.
>>>
>>>This appears to work, but is this the proper way to do it? If not, how else does one send not only the object as a parameter, but a property as well, so that any changes will be reflected outside the procedure?