>Line total and invoice total calculations should be the job of the invoice object rather than the line object. The line object shouldn't care about other line objects at all. The invoice object would need to merely ask each line object what it's total was and add them all up. In addition, you could have special line calculations for things such as averaging labor into the cost. So, if the invoice object wanted a base cost, it could call each line object's GetBasicCost() method. Or if the invoice object wanted to have the labor included in the cost it could call each line object's GetLaborCost() method.

This brings one thing I haven't thought of yet - redimensioning array properties. The easiest way to implement this is to have an array of line objects (one per line record) in the invoice class - then, we'd usually begin with one line, and as user adds line items, we'd have to increase the number of line objects. Normal VFP arrays can be redimensioned at will, and if member arrays can be redimensioned just like that, we're in the saddle. I'd prefer to have an array just to avoid the automatic names and macro substitutions, because
invoice.addobject("lineitem")

...would create just another invoice.lineitem23 object, and then we'd have to approach it using name expressions, or macro substitution. If

invoice.NoOfLines=invoice.NoOfLines+1
dime invoice.lineitems(invoice.NoOfLines)

is feasible, then there's no problem, as far as I can see. Hope someone sees beyond this, and also hope someone tried this already (my schedule is pretty tight, lately).