当用户调整对话框大小时,如何强制Windows不重新绘制对话框中的任何内容?

当用户抓取可调整大小的窗口的一角,然后移动它时,Windows首先移动窗口的内容,然后向正在调整大小的窗口发出wm_大小。

因此,在一个对话框中,我想控制各种子控件的移动,我想消除闪烁,用户首先看到Windows操作系统认为窗口将是什么样子(因为,在发送wm_大小之前,操作系统使用bitblt方法在窗口内移动东西),并且 然后 我的对话框是否能够处理移动它的子控件,或者调整它们的大小,等等,在这之后它必须强制重新绘制,这现在会导致闪烁(至少是这样)。

我的主要问题是: 有没有办法强迫Windows不要做这种愚蠢的事情? 如果窗口中的控件在窗口调整大小时移动,或者在父窗口调整大小时调整自身大小,这肯定是错误的。不管怎样,让操作系统做一个预涂,只是螺丝钉的工作。

我曾一度认为它可能与cs-hredraw和csvredraw类标志相关。然而,现实情况是,我不希望操作系统要求我删除窗口-我只想在操作系统不首先更改窗口内容的情况下重新绘制自己(即,我希望显示的是用户开始调整大小之前的状态-而不需要操作系统的任何位置)。我不想让操作系统告诉每个控件它也需要重新绘制(除非它碰巧是一个被大小调整所遮蔽或显示的控件)。

我真正想要的是:

1. 移动和调整子控件的大小 之前 屏幕上的任何内容都会更新。
2. 完全绘制所有已移动或已调整大小的子控件,以便它们在新的大小和位置上不显示任何瑕疵。
3. 在子控件之间绘制空格,而不影响子控件本身。

注:步骤2和3可以颠倒。

当我结合使用defersetwindowpos()和标记为ws-clipChildren的对话框资源时,上述三件事似乎正确发生。

如果我可以对内存DC执行上述操作,然后只在wm_大小处理程序的末尾执行单个bitblt,那么我将获得额外的小好处。

我已经玩了一段时间了,我不能逃避两件事:

1. 我仍然无法禁止Windows执行“预测性BitBlt”。 答:请参阅下面的解决方案,该解决方案将覆盖wm_ccalcSize以禁用此行为。

2. 我看不到如何建立一个对话框,其中它的子控件将绘制到一个双缓冲区。 答:有关如何要求Windows操作系统对对话框进行双重缓冲的信息,请参阅下面的john答案(标记为answer)(注意:根据docs,这不允许在绘制操作之间使用任何getdc())。

我的最终解决方案(感谢所有做出贡献的人,特别是John K.):

经过大量的汗水和泪水,我发现以下技术在Aero和XP中或在Aero禁用的情况下都能完美地工作。不存在笔势(1)。

1. 挂接对话进程。
2. 重写wm_nccalcSize以强制Windows验证整个客户机区域,而不是BitBlt任何内容。
3. 覆盖wm_大小以执行所有移动,并使用所有可见窗口的beginderwindowpos/deferwindowpos/enddeferwindowpos调整大小。
4. 确保对话框窗口具有WS-ClipChildren样式。
5. 不要使用cs_hredraw_cs_vredraw(对话框不使用,因此通常不是问题)。

布局代码由您决定——它很容易在布局管理器的代码专家或代码项目上找到示例,或者自己滚动。

以下是一些代码摘录,应该可以让您获得更多的方法:

LRESULT ResizeManager::WinProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
{
    switch (msg)
    {
    case WM_ENTERSIZEMOVE:
        m_bResizeOrMove = true;
        break;

    case WM_NCCALCSIZE:
        // The WM_NCCALCSIZE idea was given to me by John Knoeller: 
        // see: http://stackoverflow.com/questions/2165759/how-do-i-force-windows-not-to-redraw-anything-in-my-dialog-when-the-user-is-resiz
        // 
        // The default implementation is to simply return zero (0).
        //
        // The MSDN docs indicate that this causes Windows to automatically move all of the child controls to follow the client's origin
        // and experience shows that it bitblts the window's contents before we get a WM_SIZE.
        // Hence, our child controls have been moved, everything has been painted at its new position, then we get a WM_SIZE.
        //
        // Instead, we calculate the correct client rect for our new size or position, and simply tell windows to preserve this (don't repaint it)
        // and then we execute a new layout of our child controls during the WM_SIZE handler, using DeferWindowPos to ensure that everything
        // is moved, sized, and drawn in one go, minimizing any potential flicker (it has to be drawn once, over the top at its new layout, at a minimum).
        //
        // It is important to note that we must move all controls.  We short-circuit the normal Windows logic that moves our child controls for us.
        //
        // Other notes:
        //  Simply zeroing out the source and destination client rectangles (rgrc[1] and rgrc[2]) simply causes Windows 
        //  to invalidate the entire client area, exacerbating the flicker problem.
        //
        //  If we return anything but zero (0), we absolutely must have set up rgrc[0] to be the correct client rect for the new size / location
        //  otherwise Windows sees our client rect as being equal to our proposed window rect, and from that point forward we're missing our non-client frame

        // only override this if we're handling a resize or move (I am currently unaware of how to distinguish between them)
        // though it may be adequate to test for wparam != 0, as we are
        if (bool bCalcValidRects = wparam && m_bResizeOrMove)
        {
            NCCALCSIZE_PARAMS * nccs_params = (NCCALCSIZE_PARAMS *)lparam;

            // ask the base implementation to compute the client coordinates from the window coordinates (destination rect)
            m_ResizeHook.BaseProc(hwnd, msg, FALSE, (LPARAM)&nccs_params->rgrc[0]);

            // make the source & target the same (don't bitblt anything)
            // NOTE: we need the target to be the entire new client rectangle, because we want windows to perceive it as being valid (not in need of painting)
            nccs_params->rgrc[1] = nccs_params->rgrc[2];

            // we need to ensure that we tell windows to preserve the client area we specified
            // if I read the docs correctly, then no bitblt should occur (at the very least, its a benign bitblt since it is from/to the same place)
            return WVR_ALIGNLEFT|WVR_ALIGNTOP;
        }
        break;

    case WM_SIZE:
        ASSERT(m_bResizeOrMove);
        Resize(hwnd, LOWORD(lparam), HIWORD(lparam));
        break;

    case WM_EXITSIZEMOVE:
        m_bResizeOrMove = false;
        break;
    }

    return m_ResizeHook.BaseProc(hwnd, msg, wparam, lparam);
}

调整大小实际上是由resize()成员完成的,如下所示:

// execute the resizing of all controls
void ResizeManager::Resize(HWND hwnd, long cx, long cy)
{
    // defer the moves & resizes for all visible controls
    HDWP hdwp = BeginDeferWindowPos(m_resizables.size());
    ASSERT(hdwp);

    // reposition everything without doing any drawing!
    for (ResizeAgentVector::const_iterator it = m_resizables.begin(), end = m_resizables.end(); it != end; ++it)
        VERIFY(hdwp == it->Reposition(hdwp, cx, cy));

    // now, do all of the moves & resizes at once
    VERIFY(EndDeferWindowPos(hdwp));
}

也许最后一个棘手的部分可以在ResizeAgent的重定位()处理程序中看到:

HDWP ResizeManager::ResizeAgent::Reposition(HDWP hdwp, long cx, long cy) const
{
    // can't very well move things that no longer exist
    if (!IsWindow(hwndControl))
        return hdwp;

    // calculate our new rect
    const long left   = IsFloatLeft()   ? cx - offset.left    : offset.left;
    const long right  = IsFloatRight()  ? cx - offset.right   : offset.right;
    const long top    = IsFloatTop()    ? cy - offset.top     : offset.top;
    const long bottom = IsFloatBottom() ? cy - offset.bottom  : offset.bottom;

    // compute height & width
    const long width = right - left;
    const long height = bottom - top;

    // we can defer it only if it is visible
    if (IsWindowVisible(hwndControl))
        return ::DeferWindowPos(hdwp, hwndControl, NULL, left, top, width, height, SWP_NOZORDER|SWP_NOACTIVATE);

    // do it immediately for an invisible window
    MoveWindow(hwndControl, left, top, width, height, FALSE);

    // indicate that the defer operation should still be valid
    return hdwp;
}

“棘手的”是,我们避免试图与任何已被破坏的窗口混淆,并且我们不会试图将setwindowpos延迟到不可见的窗口(这被记录为“将失败”)。

我已经在一个隐藏了一些控件的真实项目中测试了上述内容,并成功地使用了相当复杂的布局。即使不使用Aero,也会有零闪烁(1),即使使用对话框窗口的左上角调整大小也是如此(当您抓取该句柄时,大多数可调整大小的窗口都会显示最闪烁和问题,例如,Firefox等)。

如果有足够的兴趣,我可能会被说服用codeproject.com或类似的实例实现来编辑我的发现。给我发短信。

(1)请注意,不可能避免一次从任何曾经在那里的物体的顶部划过。对于对话框中没有更改的每个部分,用户都看不到任何内容(没有任何闪烁)。但是当事情发生变化时,用户会看到一个变化——这是不可能避免的,而且是一个100%的解决方案。