Unable to create window without maximize box

[Robert Tausworthe]

Help! I am unable to alter the FormDocView sample program to not have the WS_MAXIMIZEBOX trait, so I can enable the context help trait and get the (?) on the title bar. I have tried & ~WSMAXIMIZEBOX on the style in .rc, to no avail. I have tried the same in Create() in CMainFrame. Can anyone help me out?

[David]

Hi Robert,

We can override PreCreate in CMainFrame to set the window styles as follows.

void CMainFrame::PreCreate(CREATESTRUCT& cs)
{
    CFrame::PreCreate(cs);
    cs.style &= ~WS_MAXIMIZEBOX ;

    // cs.style = WS_OVERLAPPED | WS_SYSMENU | WS_THICKFRAME | WS_VISIBLE;
}

This displays the maximize box disabled. The commented line creates a frame without the maximize or minimize button.

Best regards,
David

[Robert Tausworthe]

Thanks, this disables the maximize box, but does not eliminate it, as I had hoped. I guess that's not possible. Also in this respect, eliminating WS_THICKFRAME disables resizing the window, but the resizing triangle still appears at the bottom right of the window, in the status bar. I presume there's no way of eliminating that, either. The reason for this interest was my experimenting with fixed-size forms with context help (which doesn't work when there's a maximize box or minimize box). But the minimize box is just too useful to give up, so I've cobbled a toolbar function for context help instead. I can live with the disabled maximize box.

[David]

Hi Robert,

Yes, windows places some restrictions on what can be displayed when we create a top level window. If we want the context sensitive help button, we can't have either the maximize or minimize buttons. If we want to display the minimize button, then the maximize button will be displayed too, but we can have it disabled.

I'll just mention a few of other things ...

It would be possible to draw our own button for context help in the non-client area of the frame. This tends to get messy though, especially if we want to support all versions of Windows.

The gripper in the status bar is part of the status bar window. It is displayed in the status bar when the status bar control is created with the SBARS_SIZEGRIP windows style. We can create a status bar without a resizing gripper, or do away with the status bar entirely.

If you would like the frame to prevent itself from being resized we can do that by handling the WM_SIZE message in CMainFrame::WndProc. We don't need to eliminate the WS_THICKFRAME style and the status bar's gripper to prevent resizing.

Best regards,
David

[Robert Tausworthe]

My approach to handling WM_SIZE would be to save the window placement and size in a WINDOWPLACEMENT m_Wndpl structure, and then to do a SetWindowPlacement(m_Wndpl); in response to the WM_SIZE message. This by itself works, but there is flicker as the window edges are dragged around. When released, the window pops back to its saved size. The flicker can be removed by the usual shenanigans is in OnDraw(), I suppose, but that is too much coding that is inferior at best to just removing the WS_THICKFRAME style. With or without the thick frame, the gripper disappears when the status bar is hidden. With the thick frame, the window can still resized when the status bar is hidden--it's just harder to set the cursor onto the (thin) window frame. The window frame (on XP anyway) appears to be the same in either case.

[David]

Hi Robert,

Something like this might suit your purpose.

void CMainFrame::PreCreate(CREATESTRUCT& cs)
{
    // Set the initial window size
    cs.x = CW_USEDEFAULT;
    cs.y = CW_USEDEFAULT;
    cs.cx = 500;
    cs.cy = 420;
    CFrame::PreCreate(cs);
}

LRESULT CMainFrame::WndProc(UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
    // Suppress resizing
    case WM_SIZING:
        {
            LPRECT pRect = (LPRECT)lParam;
            pRect->right = pRect->left + 500;
            pRect->bottom = pRect->top + 420;
        }
        return TRUE;
    }

    // pass unhandled messages on for default processing
    return WndProcDefault(uMsg, wParam, lParam);    
}

Best regards,
David

[Robert Tausworthe]

Yes, WM_SIZING is just what is needed here. Much more elegant than trying to fix up WM_SIZE. Thanks!