>>>>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?

But total might change by other useres actions on other records somewhere in the relations too. In this sence each result is a snapshot only.

>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).

In this I do not need to recalculate all. I prefer to alter the current "total". O.K., this might be tricky. But this all depends on how far you like to go. One could think about an interface that changes the "total" with each keypress ....

We will come back to the idea that the solution depends on the interface, its problems and the complexity off the whole stuff. I have totals over n tables with hundreds of thousands if records that influence the way of calculation (so they are hard to optimize) that calculate a large time. If they would fire on each valid the customer would reject the solution.

Agnes