Here's what I would might do (if you are interested).

Create a key-based customer object that can be loaded programmatically, i.e.

oCust.loadrecord(5) where 5 is the primary key.
Add a property oBehavior

Create CustomerBehavior classes for each of the types of calculations required. For sake of argument, lets say the behavior class has a method gettotal.

From the loadrecord method, create the appropriate behavior class:

FUNC loadrecord
(get data/view/cursor here)
DO CASE
CASE custtype="A"
this.oBehavior=CREATEOBJECT("CustomerBehaviorA")
CASE custtype="B"
this.oBehavior=CREATEOBJECT("CustomerBehaviorB")
...etc
OTHERWISE
this.oBehavior=.NULL.
ENDCASE
ENDFUNC

In the gettotal method of the Customer class,

FUNC gettotal
LOCAL nTotal
IF VARTYPE(this.oBehavior)="O"
nTotal=this.oBehavior.gettotal()
ELSE
(Raise Error)
nTotal=.NULL.
ENDIF
RETURN nTotal
ENDFUNC

In the gettotal method of the CustomerBehavior object, put in whatever code is necessary to get the total. Since the CustomerBehavior object is dependent on the customer object, you can make some assumptions about environment - for example, the customer table is pointing to the record you want to calc for.

To get values for many customers, get a list of keys for customers you want to calc for. Then (assuming, for example the list is in a cursor):

SELECT c_customerlist
nTotal=0
SCAN
oCustomer.load(c_customerlist.nprimarykey)
nTotal=nTotal+oCustomer.gettotal()
ENDSCAN

This is sort of a hybrid OOP/DB approach, I think. The extra advantage is that you can group many different methods by Customer type this way, not just gettotal. Adding a new type requires implementing a behavior type and adding the conditional creation of the behavior class in only one place - the load method. The interface by which other objects talk to the customer object is consistent regardless of type.

Of course, there are other considerations, like performance (iterative operations can be time consuming), architecture, etc. that may necessitate a different approach.

This is one place where the VFP object model can be a pain. What you are really doing (a la Java) is creating an interface. The interface for the behavior object in the above example is gettotal. What would be nice is to create the interface and require that all classes that implement the interface be required to have an explicit implementation (that's how you do it in Java). In VFP, you either create a base class and override the default behavior in each subclass, or you create all of the classes independentlym in which case you lose inheritance.

But I digress. Well, you can't have everything...

Hope this helps.


>>Can't I have a column in the grid that is the result of a calculation? The calculation would be based on the class method....
>
>No. Again, I would suggest a calculated field in a SQL statement or view using a UDF at the time the view was queried that populates a calc field and controlsource the column to that field.