Just a follow-up... I was able to kludge up something that sort of works. Basically implemented as a normal/maximize button rather than having the window resizable by dragging (since there were no events that I can trap to detect the situation). Oddly enough the fact that the screen in question contained a BROWSE ended up making it easier (the particular screen used a BROWSE -- which was the only portion taht really needed to get resized -- the other portions could sipmly be repositioned as a child window). Normally the fact that BROWSe windows don't participate in a READ makes it a pain to deal with -- but because a BROWSE doesn't participate in a READ, that means BROWSE windows remain resizable. Second item that helped was the discovery that although a window participating in an active READ, the parent of such windows, as long as it doesn't contain any controls participating in a READ remain resizable.

The one thing that did throw me for a loop however -- the fact that the WLCOL() and WLROW() are refrenced from the main FoxPro window and not the containing window so doing something like MOVE WINDOW foo TO WLROW(),WLCOL() didn't give the expected result. It also wasn't helping me that some windows were using a monospace font (as those portions were originally from a DOS version, which assumed a monospace font), while others were using a proportional one (not only because monospace looks ugly, but most users would associate the look to DOS) so computations on size and coordinate values had to take into account of the context in which I was looking at.