>>There's a thought. That sounds workable. Thanks.
>>
>>My initial impression is child forms are somewhat unruly (or maybe underdeveloped). Do you agree or disagree?
>
>The you want the standard answer or the answer from experience? Standard: it depends. From experience: it depends.
>
>A child form is usually a free-floating modal form, called from the parent form to enter some data (or just parameters) that have no place in the main form - are not part of the regular data entry, are related to a side task (say, printing a report, entering a new record into a lookup table, searching, looking up a pop-up grid etc). They may or may not share the datasession with the parent, they may be modal (more often than not), and they may return a value (or object) to the caller form.
>
>Now if you wanted the child form within the parent form - that sounds like your parent form is a MDI form, but in the MDI paradigm child forms are free floating inside the parent form. This paradigm was invented for apps that handle one file per window, like Word.
>
>Now you want the child form to be in a fixed position over your form - which makes it a perfect candidate to not be a form at all, but rather a container. Sergey's already suggested a pageframe (tabbed or tabless - up to you) to hold your grids, which I would also suggest - except he's faster, as usual :).

I'm not sure I follow. Why would a free-floating modal form need to be a child form at all? Any form can be that. What I was looking for was a form that would exist strictly within the context of the parent, including positioning. It's no longer an issue, Sergey steered me to the path of righteousness, but I guess I remain curious. What use are FoxPro child forms, anyway? I would especially be interested in the input of those who have used them.