创建客户区窗口，列表框之间项的拖拽操作

C++ Q&A 专栏...
创建客户区窗口，列表框之间项的拖拽操作......

原著：Paul DiLascia
翻译：Northtibet

原代码下载：CQA0410.exe (234KB)
原文出处：MSDN Magazine October 2004 (C++ Q&A)

1. 创建客户区窗口
2. 列表框之间项的拖拽操作

在发送绘画(paint)消息时，系统是如何识别某个窗口的客户区或非客户区？当我用 ::CreateWindow 创建窗口时，如何指定客户区矩形？

Vipul Solanki

在创建窗口时不必指定客户区，当收到 WM_NCCALCSIZE 消息时才指定客户区。不管什么时候，只要 Windows 想知道窗口客户区的大小，它便会发送这个消息。在 MFC 中实现 OnNcCalcSize 处理例程。该处理函数有两个参数，从 WPARAM 和 LPARAM 转换而来：

void OnNcCalcSize(BOOL bCalcValidRects, NCCALCSIZE_PARAMS* lpncsp);

　　该函数告诉应用程序是否“计算有效矩形”（稍后还要讲到）；NCCALCSIZE_PARAMS 结构保存三个矩形数组，第一个保存窗口的客户区。以下是实现 OnNcCalcSize 的基本模式：

// got WM_NCCALCSIZEvoid CMainFrame::OnNcCalcSize(...){// do default thing (important!)CFrameWnd::OnNcCalcSize(...);CRect& rc = (CRect&)lpncsp->rgrc[0];// adjust rc; eg, rc.DeflateRect(...);}

　　我写了一个小程序，NCCalc，它将标准客户区四周收缩7个像素并将该区域绘制成 3D 外观颜色（典型的浅灰色）。Figure 1 列出了源代码的精华部分。重要的函数是 OnNcCalcSize，它调整客户区矩形大小，OnNcPaint 绘制边界。绘制代码简单直白，我就不再赘言。具体细节请下载源代码。
　　如果你改写主窗口的 WM_NCCALCSIZE/OnNcCalcSize，一定要确保调用基类的默认窗口处理例程，以便实现缺省处理。这样程序一运行便会有得到默认的客户区矩形，然后你可以调整其大小。同样，还应该在OnNcPaint/WM_NCPAINT 中调用基类默认的处理过程。否则 Windows 不会绘制边界，滚动栏或其它标准非客户区元素。如果你实现自己的窗口类，像定制工具栏或调色板，其中要计算客户区矩形并进行绘制处理，你可以不必调用基类默认的窗口过程。随便哪种方法，当窗口收到 WM_NCPAINT 消息时，你都得负责绘制整个非客户区。
　　有些人可能想知道 bCalcValidRects 以及 NCCALCSIZE_PARAMS 中的其它矩形是做什么用的。如果读一下文档，你会发现 WM_NCCALCSIZE 的语义相当复杂。文档中说如果 bCalcValidRects 为 TRUE：“应用程序应该指示客户区的哪一部分包含有效的信息。系统将有效信息拷贝到新客户区中指定的区域”这种情况下，“第二个[矩形]在被移走或重新调整大小之前包含该窗口客户区的坐标”尽管所有这些描述好像够清晰，我还是不能完全把握。我也从来没有见过那个应用程序使用这些额外的矩形。我见过的应用程序都忽略 bCalcValidRects 并简单地修改第一个矩形，在 NCCALCSIZE_PARAMS 中设置客户区。
　　我之所以提到这个，是因为按照文档所言，如果 WPARAM/bCalcValidRects 是 FALSE，那么 LPARAM 不会指向 NCCALCSIZE_PARAMS 结构，而是单个的 RECT，客户区，然而 MFC 在所有情况中将 LPARAM 强制转换为 NCCALCSIZE_PARAMS。这似乎是个bug，虽然只要你仅修改 NCCALCSIZE_PARAMS 中的第一个矩形，你的程序是绝不会垮掉的。我运行了一些测试程序，确定当第一次创建窗口时，Windows 仅有一次用 bCalcValidRects=FALSE 来发送 WM_NCCALCSIZE。随后，不论窗口如何调整大小，Windows 都用 bCalcValidRects=TRUE 来发送 WM_NCCALCSIZE。你必须对两种情况都设置客户区，以便正常显示你的窗口。
　　唉，恐怕到现在我都没有阐明 bCalcValidRects 到底是做什么用的。微软的大佬们也没有给出足够文档来说明这个神秘的参数，只是说它是从 Windows 3.1 远古时期延续下来的。如今只要你始终对两种情况都作处理，并且只修改第一个矩形，一切都会OK。

我正在做一个商业棒球游戏程序。在我的用户界面中，我想让用户能在两个列表框之间实现拖拽操作。 MFC 有没有简单的方法来做到这一点？

Tom Tippett 　

针对这种情况，MFC 没有内建的处理方法，但用两种方法可以实现你的要求。COM 有其自己的接口来处理应用程序之间常规的拖拽操作。它需要实现几个接口：IDropTarget，IDropSource 和 IDataObject，此外还有一个函数，DoDragDrop 实现具体的拖拽操作。使用 COM 来实现拖拽操作需要编写大量的代码，这样有可能超出了能力所及。再说使用 COM 来实现这个功能也有些夸张，因为 COM 本身是专门设计用来以更一般的方式实现应用程序之间的交互。如果你仅仅是想在应用程序中将一个项目从一个控件拖拽到另一个控件，那么自己编写代码来的更简单和容易。
　　我写了一个小类库，其中包含一个类，CDragDropMgr，用这个类可以在自己的应用程序窗口间添加拖拽行为。我还写了一个测试程序，DDTest，示范了如何使用 CDragDropMgr 类（参见 Figure 2）。Figure 3 是程序运行的画面。DDTest 有两个列表框和一个编辑框。你可以将第一个列表框中的项目拖拽到第二个列表框，或者编辑框。此外，你还能在第二个列表框里通过拖拽重排项目。DDTest 就是使用 CDragDropMgr 来实现上述这些功能的。下面我首先示范如何使用 CDragDropMgr，然后在探讨它的工作原理。


Figure 3 运行中的 DDTest

　　为了使用拖拽管理器，首先要在主窗口或对话框中实例化 CDragDropMgr，然后用一个表对之进行初始化，就像下面的代码这样：

static DRAGDROPWND MyDragDropWindows[] = {   { IDC_LIST1, DDW_SOURCE },   { IDC_LIST2, DDW_SOURCE|DDW_TARGET },   { IDC_EDIT1, DDW_TARGET },   { 0, 0 },};m_ddm.Install(this, MyDragDropWindows);

　　我的专栏的爱好者们知道我编程的五大秘诀之一便是 一张表胜过一千行代码。表的形式比长长的一串过程代码更加简练、优雅、可靠和可维护。在本文的例子中，表告诉拖拽管理器哪个子窗口是拖拽操作的源和/或目标。每一个表入口都有一个子窗口ID以及一个 DDW_SOURCE 和 DDW_TARGET 的组合标志。在 DDTest 中，第一个列表框是源，第二个列表框既可以是源，也可以是目标，编辑框只能是目标。但是不管怎么样，不要忘了在表的末尾加上 NULL！
　　一旦你用窗口表对拖拽管理器进行了初始化，下一步便是改写主窗口的 PreTranslateMessage 函数以便将消息传递给拖拽管理器：

BOOL CMyDlg::PreTranslateMessage(MSG* pMsg){   return m_ddm.PreTranslateMessage(pMsg) ? TRUE :      CDialog::PreTranslateMessage(pMsg);}

　　一切准备就绪，当用户试图从一个窗口到另一个窗口实施拖拽操作时，拖拽管理器便会察觉到并通知应用程序要做相应的处理。CDragDropMgr 可以发送四个消息/通知：WM_DD_DRAGENTER、WM_DD_DRAGOVER、WM_DD_ DRAGDROP 和 WM_DD_DRAGABORT。收到这些消息/通知后，做什么样的处理由你来决定。WM_DD_DRAGENTER 和 WM_DD_DRAGDROP 是拖拽操作必须要做的处理。其它两个可选。WM_DD_DRAGABORT 用来处理用户取消操作时的清除工作。WM_DD_ DRAGOVER 使你能够在用户实施拖拽操作而移动鼠标时进行连续不断的处理。DDTest 这样简单的程序不需要处理这些消息。
当拖拽管理器发送 WM_DD_DRAGENTER 消息时，它在 LPARAM 中传递一个 DRAGDROPINFO 结构。你的任务是将 DRAGDROPINFO::data 指向一个包含你想要拖拽数据的 CDragDropData 实例，然后返回 TRUE。如果拖拽是不允许的（也许用户单击了列表框中的某个死区(dead area)）则应该返回 FALSE，并不要设置 DRAGDROPINFO::data，CDragDropData  类似 COM 的 IDataObject，但要简单得多：它保存拟拽动的数据。CDragDropData 有三个虚拟函数：OnGetDragSize 获得一个拖拽图像的绑定矩形，OnDrawData 绘制拖拽图像，OnGetData 获取数据本身。我在我的库中提供了一个叫 CDragDropText 的类，它实现了这些函数，用来处理文本拖拽操作。它将文本保存在一个 CString 中。OnGetData 返回这个串，OnGetDragSize 计算该文本矩形，OnDrawData 则绘制该文本：

void CDragDropText::OnDrawData(CDC& dc, CRect& rc){  dc.DrawText(m_text, &rc, DT_LEFT|DT_END_ELLIPSIS);}  

　　如果你想得到这个文本，你唯一需要调用的函数是 OnGetData，拖拽管理器需要时在其内部调用 OnGetDragSize 和 OnDrawData。
　　那么所有这些工作是如何实现的呢？当 DDTest 收到 WM_DD_DRAGENTER 消息，它调用一个内部函数 GetLBItemUnderPt 来确定光标下是哪个列表框（如果有的话）。然后 DDTest 以这一项的文本作为数据创建一个 CDragDropText 对象并将 DRAGDROPINFO 中的 data 指针指向该对象：

// in CMyDlg::OnDragEnterDRAGDROPINFO& ddi = *(DRAGDROPINFO*)lp;int item = GetLBItemUnderPt(...);if (item>=0) {  CString text = // get item text  ddi.data = new CDragDropText(text);  return TRUE;   // allow drag-drop}return FALSE; // nothing to drag      

　　由 CDragDropMgr 来做剩余的工作。当用户拖拽它时在周边绘制文本并根据光标是否出于拖拽目的地上方而相应地改变鼠标光标。
　　当用户松开鼠标，CDragDropMgr 便给应用程序发送一个 WM_DD_DRAGDROP 消息。暗示数据已经拖拽完成。对于 DDTest 而言，这意味着如果鼠标出于编辑框上方，则要设置编辑框中的文本，或者如果鼠标是在列表框上方，则要将文本添加到列表框中。在真正实现中，DDTest 稍显复杂，因为它可以让用户重新安排第二个列表框中的项目。DDTest 有代码可以察觉是否需要添加文本或修改列表框中文本的位置。具体细节就留给你来做了，OnDragDrop 实现的基本要点都是一样的：

// OnDragDrop handlerDRAGDROPINFO& ddi = *(DRAGDROPINFO*)lp;void* data = ddi.data->OnGetData();// do something with datareturn 0;      

　　以上都是关于文本的操作，如果要拖拽其它类型的数据怎么办呢？为此，你必须通过 CDragDropData 派生并改写三个基本函数来扩展我的库。例如，为了拖拽图像，你得派生一个 CDragDropImage 类，在这个类中，OnGetData 返回 BITMAP 或 CBitmap，OnGetDragSize 返回位图的尺寸，OnDrawData 调用 BltBit 或其它什么函数来绘制该位图。
　　我已经示范了 CDragDropMgr 的使用方法，但它是如何工作的呢？基本思路很简单。CDragDropMgr::PreTranslateMessage 查找发送到拖拽源窗口之一的鼠标消息并发送相应的通知到你的应用程序主窗口。CDragDropMgr 实现了一个典型的具有三种状态的有限状态机：NONE、CAPTURED 和 DRAGGING。当用户按下鼠标键，CDragDropMgr 进入 CAPTURED 状态。当用户移动鼠标，则进入 DRAGGING 状态。具体细节简单直白。
　　CDragDropMgr 使用 PreTranslateMessage 而不是子类化主窗口，因为它需要解释发送到可能的拖拽源窗口之一鼠标消息，该拖拽源窗口由前述的拖拽窗口表确定。MFC 的优点之一是它在主窗口中仅通过虚拟 PreTranslateMessage 方法便可以过滤所有子窗口消息。这使得 CDragDropMgr 可以仅在单一的函数中便可截获发送到任何潜在拖拽源窗口的鼠标消息，从而避免了必须子类化每一个窗口。当 CDragDropMgr::PreTranslateMessage 看到 WM_LBUTTONDOWN，它便查找该窗口句柄（HWND）以便检查它是否被列入源窗口表。如果它是一个源窗口，则进行拖拽初始化，否则忽略该消息。
　　拖拽数据的机制是很简单直白的，甚至有些单调无趣，所以细节我就不再赘言。唯一一个亮点是 CDragDropData 使用 CImageList 来绘画。如果你实现自己的拖拽管理器，我鼓励你也这么做，CImageList 包含如下几个函数：BeginDrag、DragEnter、DragMove 和 EndDrag，用它们可以很快解决比特绘画问题，它们使用特有的光栅操作使图像呈半透明，从其以前位置擦除等等。
　　没有 CImageList，这些绘制细节冗长乏味。有了它，CDragDropMgr 只要将拖拽图像绘制到图像列表位图一次即可。当用户初始化拖拽操作时，CDragDropMgr 通知主应用程序，该主应用程序将 DRAGDROPINFO::data 设置为一个 CDragDropData，正如我前面描述的那样。然后拖拽管理器调用 CDragDropData:: CreateDragImage （参见 Figure 4），它创建一个包含要绘制的图像列表。CreateDragImage 调用虚拟函数 CDragDropData::OnGetDragSize 来获取拖拽图像的尺寸，CDragDropData::OnDrawData 将数据绘制到图像列表的位图中。一旦完成了些工作，CDragDropMgr 调用图像列表函数绘制拖拽期间的图像。例如，每次用户移动鼠标，CDragDropMgr 都调用 CImageList::DragMove。还有比这更容易的吗？其优美之处在于这个代码完全是通用的。为了处理新的数据类型，你只要实现 OnGetDragSize 和 OnDrawData 即可。
　　Figure 2 和 Figure 4 是 DDTest 中的关键代码。有关其它细节请下载完整的源代码。祝编程愉快！

向 Paul 提问和评论请发到 [e-mail].
　 作者简介
　　Paul DiLascia 是一名自由作家，顾问和 Web/UI 设计者。他是《Writing Reusable Windows Code in C++》书（Addison-Wesley, 1992）的作者。通过 http://www.dilascia.com/ 可以获得更多了解。 　 本文出自 MSDN Magazine 的 October 2004 期刊，可通过当地报摊获得，或者最好是 订阅
本文由 VCKBASE MTT 翻译