Duh! I think I should slap myself upside the head... ;-)

OK, I just thought of a use for this technique you may or may not have thought of (and I'd love for someone more knowledgeable to jump in and confirm or deny what I'm about to post)....

(!)ADO(!)

If you create a wrapper class with interfaces to create the oForm.oRecord with SCATTER, passing the oForm reference, then you can also exchange that wrapper with one that creates an ADO.RecordSet object and then creates oForm.oRecord properties (=fields). Hmmmmm...this allows you to scale up to ADO and client/server with -zero- form changes.... I like it.

BTW, I have yet to see where ADO is "native" to VFP6...do you see it?





>Scatter Name Thisform.scobject, so it's scoped within a form. Surely, it should be cleaned up in Form.Destroy event
>
>>Ed....I think you missed the question. The question is, are the SCATTER objects scoped to the form or the application? So...if I SCATTER NAME oMaster on one form and SCATTER NAME oMaster on another form, isn't oMaster scoped to the application and *not* the form? And doesn't that create a problem?
>>
>>
>>>Another form instance (they are all instaciated from the same class) will just contain new object(s). If you instanciate form with a textbox, the new form instance will contain similar but another textbox, it's the same case. Also, all 'scatter' objects live as long as editing session lasts. There is no necessity to keep them if user simply view record(s).
>>>
>>>>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?