snip
>>
>>1. have some sort of form handling mechanism to determine which child forms are instantiated and close them when parent is closed.
>>2. prevent user from launching same child form twice.
>
>Yes to the above. I guess I am spoiled in that the framework I use does all that stuff for you.
>

I'm pretty sure all of the frameworks will support that design. I know at least 3 do.

>>3. constantly check if child/parent exists if you need to update related form objects from a related form's logic.
>
>Not sure what you mean by this, so I don't know if you have to do it or not.
>

Automatically refreshing data on other open forms sharing datasessions is also easily implemented whether you are using a framework method call or your own logic.

>>These (and some I haven't thought of yet) are not relevant when using formsets. I'm still interested in hearing why formsets are discouraged.
>>
>
>I don't know. Also, I just looked at the 8.0 doc and 7.0 Hackers and neither of these say that these a backward compat things and/or not to use them. So, who discourages them?
>
>BOb

As I recall, one of the turnoffs for formsets goes back to VFP3 when people were doing automatic conversions from 2.6. The VFP form conversion wizard defaults to using formsets which is the equivalent of a 2.6 screen set. But it created a formset on every form converted whether it was in a screen set or not. Including the "Formset" in containership code like Formset.Form1.oThis.oThat meant additional typing and added another layer of objects to traverse.

The advice then was to move to private datasessions and to the new data environment capablities of forms in VFP3, which made parent/child relationships much easier to setup. Formsets really don't buy you much and carry some baggage. The native DE functionality of forms in VFP really don't need an additional formset layer to work great right out of the box.