>>>Matt,
>>>
>>>I've found this approach a real pain. I've decided to run a timer instead. The calculation will be only activated if the user stops for a while.
>>>In fact I use a methof of the grid to decide if the recordpointer is moved (Using AFTERROWCOLCHANGE but only from VFP 7 (you missed to enter your version))
>>>This (re) starts a timer. The timer event will do the calculation. I use thus for refreshes I need too.
>>
>>Shouldn't changing the value of any of the fields which influence the total actually trigger the calculation? IOW, moving up and down a row doesn't change the total; changing numbers does.
>
>It could be a subtotal of some child. In a multiuser app it might be a goo idea to get the current (sub)total.

I assumed a policy where there's a pessimistic lock on the parent record, i.e. can't have two guys editing the same document at the same time. Comparable to two cooks doing the same dish - they can communicate at real time all they want, and still can't be trusted to get the amount of salt right, and somehow we expect two users, who may not even know of each other, to cooperate seamlessly? I say xor them, let them live like pigeons - if one gets in, others stay out (of the document). (the pigeon reference comes from "every now and then someone's out through the window")

>If I change a number, it should not change the total until I commit the change. This is normaly done by changing the record or a other save operation. Each of those triggers finaly the recalculation.

It should not update the total anywhere until I click save on the document, but meanwhile it should show me what the total would be, so I'd have some feedback and means of controlling my entries. Or I may want to play a what-if, so show me wwibiiwb (what would it be if it would be) - if I don't like what I get I may not save at all. Don't force me to save just to see the total, because if I don't like it I maybe won't be able to remember how was it before, so how do I revert?

So we're talking about two kinds of totals here - the visible temporary total (which is, I guess, the subject of this thread - see buffering in the title) of not-yet-saved data, and the total which may be saved in the end and become visible to other users (which I think you were referring to).