>>>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.
>
>The only trouble is your wish for it to have a fixed position. The users have got this habit to move windows as they like, and if you create a form which can't move, they'll be at least somewhat confused, or maybe even pis*ed off.
>
>As for the general role of child forms in a MDI form, I haven't found use for them yet, not in a VFP app. Even in one case where I have an OCX editor within the app, the editor's window(s) reside(s) in _screen. This doesn't mean there isn't an app which would benefit from a MDI, just means I didn't write one yet.


Again, my objective was to display multiple grids in the same place on a form. I wanted it to act just like an ordinary grid on a form, except the ControlSources need to be different. For some reason child forms came to mind. Sergey's suggestion of a pageframe is cleaner and certainly easier.