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?