What you're talking about sounds like the kind of situation where you'd use a splitter window.
Rather than give the Edit controls a thick frame and hosting them directly in the main windows, you create them without a frame and host them in a splitter window which is the direct child of the main window.
With the splitter approach the thick frame would be provided by the splitter, round the outside, plus the splitter bars, between the child windows. When the splitter bars are moved it's the splitter which resizes the controls it holds.
The splitter window is responsible for drawing a splitter (or more than one) and filling in the background of any uboccupied space. It is also responsible for responding to messages that move the splitter and adjusting the size of it's children as required. While the standard splitter is for two child controls, but it should be easy enough to generalize.
(An API call which might be helpful when painting the splitter window is DrawEdge
it know how to draw the standard edges of buttons and windows.)
I suppose you could get the Edit controls to work together, cooperatively, without the splitter if you subclassed them suitably. But I've never seen it done, and it would prob. be rather messier than the usual splitter approach.
When I've done this kind of thing I've used WTL, which provides a splitter class; and I know MFC provides a spliiter implementation. But neither WTL nor MFC's splitter's work with several controls in a row.
And there's this, which I've just found, which works with the WinAPI directly. Not sure how good it is, but it will help you identify which message you need to handle.
Win32 splitter window project
(I have downloaded and built the sample projects, and it does the normal splittery thing. It flickers as the painting code is rather basic, as it's just a a demo. But it is using WinAPI rather than MFC or WTL. You may well be able to find a better example, given a bit more time.)