FindWindow to get the main window, then call FindWindowEx the appropriate number of times and in the appropriate manner to get the desired child window and then call SetWindowPos to position the child window.FindWindow would be enough.
Indeed you can and you do. You need to identify the type of the window you want and the number of siblings of the same type before it, and then do the same for each container it is in, all the way up to the parent form. You call
FindWindow to get the handle of the parent form, then you call FindWindowEx and specify that handle as the parent to get the handle of a child window. Once you have the handle of a child container, you can specify that as the parent to get its child windows. When you call FindWindowEx, you specify the type of the child window to get the first child of that type. You can then call it again and specify that you want to find the next child after that previous handle to get the second child of that type and so on. As an example, let's say that you want the second Edit window inside the second Container window:FindWindow to get the top-level window.FindWindowEx to get the first Container, specifying the handle from step 1 as the parent.FindWindowEx to get the second Container, specifying the handle from step 1 as the parent and to get the window after the handle from step 2.FindWindowEx to get the first Edit, specifying the handle from step 3 as the parent.FindWindowEx to get the second Edit, specifying the handle from step 3 as the parent and to get the window after the handle from step 4.
That seems to suggest that there is no child window. A window is defined by a handle so if there's only one handle then there's only one window. It seems like what looks like a child window is actually just drawn on the top-level window, much like if you used GDI+ to draw buttons on a Windows Form. Like I said in the first place, what you can do depends on how the application is built. It sounds like it's built in such a way that what you want to do is impossible.
