Adjusting vertical frame

hi,

I'm wondering if it's possible to adjust only the vertical of a frame/window/dialog?

I've searched various resources (including msdn), but I can't seem to locate (or figure out) how to go about adjusting a window/dialog/frame only vertically, only on one side; and also adjust a window/dialog/frame within an existing frame and adjust any other adjoining frames accordingly.

I know I can WS_SIZEBOX a frame, but that allows adjusting on all sides.

Set up would be something like;
MainFrame1>
-ChildFrame1
-ChildFrame2
Both ChildFrames are snapped within the MainFrame side by side. Adjusting the vertical bit in the middle, enables sizing both ChildFrame1/2. Not equally, but according to user adjustment.


Any tips or pointers would be much appreciated, thanks!

MoveWindow Function ()

Ok.

Code:

---

GetClientRect(g_hWndMainFrame, &rctMainWnd); //main window. All sides adjustable.
MoveWindow(g_hMainFrame,0,0,rctMainWnd.right/2, rctMainWnd.bottom, 1); //main dialog. Only want to adjust the vertical sides, not the top/bottom.

---

How does one grab just the vertical side only (main dialog), or disable moving some sides and not others? I don't want the whole thing resizing. I want to be able to have the top/bottom of any child frame (main dialog) move with the main window, but be able to size the sides only.

Just don't modify it. There is no function that explicitly calls only one or the other.

Or do you mean you want to put the slider control in the window for only one or th other, in which case you would do that when you create the window by oring WS_HSCROLL or WS_VSCROLL to the window style.

Or do you mean you only want the user to be able to resize it in one direction or the other?

Add a sizing border and handle WM_SIZING. Make sure that the left and right members of the rect* (LPARAM) don't change or exceed the desired width.

Another alternative is to handle WM_NCHITTEST. In it call DefWindowProc to get the current hit-test value, if it's either of HTRIGHT or HTLEFT then return HTCLIENT or HTBORDER and the cursor won't change to the sizing one, thus disabling it.

Code:

---

case WM_NCHITTEST:
{
    LRESULT lRes = DefWindowProc(hWnd, msg, wParam, lParam);
    if(lRes == HTLEFT || lRes == HTRIGHT)
    {
        return HTBORDER;
    }
    return lRes;
}
break;

---

If you don't want them to be able to click the corners to resize the window add HTBOTTOMLEFT, HTBOTTOMRIGHT, HTTOPLEFT and HTTOPRIGHT to the above. If you'd like the corners to be used, you'll have to implement WM_SIZING as above to enforce the width constraint.

For a dialog it's one of those times you have to explicitly set the return value.

Code:

---

#include <windowsx.h>
INT_PTR CALLBACK DlgProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    static BOOL bRecursing = FALSE;
    switch(msg)
    {
        case WM_NCHITTEST:
        {
            CheckDefDlgRecursion(&bRecursing);
            LRESULT lRes = DefDlgProcEx(hWnd, msg, wParam, lParam, &bRecursing);
            if(lRes == HTLEFT || lRes == HTRIGHT)
            {
                lRes = HTBORDER;
            }
            return SetDlgMsgResult(hWnd, msg, lRes);
        }
        break;
    }
    return FALSE;
}

---

WM_NCHITTEST looks like what I'm after.

Thanks adeyblue for the code snippets! Really helped! :). Now just have to figure out how to properly implement them :/.

Cheers!

Quote:

---

Another alternative is to handle WM_NCHITTEST. In it call DefWindowProc to get the current hit-test value, if it's either of HTRIGHT or HTLEFT then return HTCLIENT or HTBORDER and the cursor won't change to the sizing one, thus disabling it.

---

This seems quite kludgy.

If I go to the Menu in the upper left (Alt+Space) and hit resize, does it still prevent me from resizing? I'd almost bet not, but I'm in Linux at the moment.

Nah it doesn't, you need the WM_SIZING solution as well to prevent that. I wouldn't call the other a kludge though, there's not much worse than getting a visual cue saying "Hey look, you can do this here" when in fact, you can't.

Ah, ok. For the visual cue then, perhaps a combination of the two.