OIC! Hmmm...very interesting...so, in essence, you have instituted another buffer comprised of the SCATTER object. That works. But then how is the SCATTER object referenced in the heirarchy? For example, lets say I launch a form with a table called master. I SCATTER to oMaster, giving me oMaster.Name, oMaster.Company --- et al....what happens if I launch another instance of that form? Will I overwrite the oMaster object?



>You mean, that I can link 'record' (third) object property to Form.Controlsource? Actually, it's evolved to this, and IMO it's called business object. I just try to show the evolution process, it had to be done step-by-step, and, honestly, this 'third' object, as i said before, rarely exists in my projects (only in a case client requests sophisticated processing of multi-user save data collisions).
>
>>OK...I think I see the SCATTER stuff and how it could be useful...but then why not use the object reference as the ControlSource in Form controls?
>>
>>(You are starting to convince me, Ed)
>>
>>
>>
>>
>>>In some sense, everything is similar. Just look at this as OO-version of standard xbase approach.
>>>Instead of giving a code, I want to extend a little bit here to show your another similarity. When you use buffering, you have OLDVAL() and CURVAL(), right? Let say, when I start to edit a record I create record object (e.g. using NAME clause of Scatter command, if someone doesn't like scatter s/he can be sure that i create object differently), when it's going to Save.Click i create object from the same class and initiate it from record.fields again, i.e. I have 2 objects, one of them is equivavlent to OLDVAL() and another one is CURVAL(). Also, I can have the third similar object, which holds real user's entries. Is it not nice? Is it not powerful? Is it more like Fox2x, or truly OO-way?