Hi Jim,
Is the re-assignment of loParms necessary in the statement:
loParms = Broker.GetTotal(loParms)

Thanks.
Kam.
>Renoir,
>
>You use properties. For example;
>
>Object1 has a value that object2 needs, well object2 can refer to Object1.PropertyName to get that value.
>
>Even better is to use parameter objects to move data around. Example Object1 has a method that does some stuff and creates some values. Object2 can do something like this;
>
>

>* Some method in object2
>loParms = CreateObject("Relation")
>loParms.AddProperty("cName","")
>loParms.AddProperty("nTotal",0)
>loParms = Object1.SomeMethod(loParms)
>* Now object1 does it thing and puts the results into the object passed to it
>?loParms.cName && Show the name passed back
>?loParms.nTotal && Show the total passed back
>

>
>Of course object2 needs to know what object1 wants as values and what it will return as values but that is required in any call anyway.
>
>The big plusses for this method;
>
>1. Vistually unlimited number of paramters passed into the method
>2. Virtually unlimited number of values passed back
>3. All values are encapsulated in an object
>4. No public vars (also no private vars they can all be local)
>5. Realtively easy to extend methods later on
>6. Object2 can pass the return object back to some other object if needed
>7. Relatively easy to create a broker object to insulate object1 from object2
>example:
>
>

>* Some method in object2
>loParms = CreateObject("Relation")
>loParms.AddProperty("cName","")
>loParms.AddProperty("nTotal",0)
>
>loParms = Broker.GetTotal(loParms)
>* In this case object2 doesn't even know the name of object1
>* As a matter of fact Object1 may not even exist and the Broker object
>* may create it only when it is needed
>
>?loParms.cName && Show the name passed back
>?loParms.nTotal && Show the total passed back
>