There are a couple of APIs you can use to get the windows' positions. The difference is in how they return the coordinates and in what form and what extra info they can return (other info you might need btw).
Note that since you're planning to use the
MoveWindow API the coordinates need to be in screen coordinates. So it might be needed to convert the returned coordinates or width and height into screen coordinates first. But also note that you can also use the
SetWindowPos API which makes it also possible to set the Z-order of the window. Which is actually something you'd might to consider if you want to make a window 'following' another window, while being visible but remaining inactive, depending on what that 'following' window exactly is meant to do.
The
GetWindowRect is the simpliest API you can use to get coordinates. It returns the dimensions in a
RECT structure as screen coordinates.
The
GetWindowInfo returns the window coordinates in the
rcWindow member of the returned
WINDOWINFO structure.
The
GetWindowPlacement returns the state and the restored, minimized, and maximized positions of a window in the returned
WINDOWPLACEMENT structure.
But, depending on what the function is of that 'following' window, you might also want to consider using an API like
GetClientRect which will, like
GetWindowRect, return dimensions in a
RECT structure, but for the client area of the window. Which is the area inside the borders of the window. Because borders are not always the same size, especially not across different Windows versions, it is not as easy as subtracting or adding a fixed number to compensate for the border width. That is something you should never do and is bound to give you problems and wrong results. Hence the use for the
GetClientRect API.
---
If you ever come across another similar problem of not knowing what API to use. You can look in the MSDN library for the list of available APIs by subject. For APIs regarding windows you have the list
here.
---
PS: To make a window 'following' another window, you need that main window to be subclassed so that your code is informed when that main window is moved around, minimized, restored, destroyed, etc... The poor-man's solution is to use a timer which checks the main window every so often, but this is really something you should try to avoid to do for various reasons, especially performances reasons!! It is also considered bad coding in many cases. Also consider making that main window a parent of the 'following' window (see parent/child systems).