>1) like REMOTE VIEWS vs SPT, "Do Form" is a wrapper around object instantiation that has side effects ie creating it's own variables

What variables? The one created implicitly to reference the form? you have control of this using the NAME clause...

>2) you have less intricate control

Examples?

>3) it is slower (at least it was - haven't tested in 6)

If this is true (I have never heard this argument), it's not a big enough difference to make it an issue for me. When do you ever call a form in a tight loop?

>4) you have to work "Backwards" to get just an object ref - that is - add clauses like "DO FORM NOSHOW NAME o LINKED" vs o = create('form')

I just don't see the practical difference between:

DO FORM MyForm NAME oForm

and

oForm = CREATEOBJECT("MyForm")


>5) I hold it out as a beginners technique - I am not alone. - I learned this when first going to work for MEI a few years ago when I was on your side of the issue.

Anybody else see the circular reasoning here?

I'll state again: I have never heard a good argument against DO FORM, and I have a long list of reasons that I don't like CREATEOBJECT for forms.

>Please tell me you are not using the VFP data environment ...

Please give me a good reason that I should not. I build my DE at design time using the form designer, and control opening of tables and paths from framework code running from the form's Load event. I have reviewed several commercial frameworks, and still have not found a reason to abandon my technique.