VC++界面类编程实例.doc.doc

A?Drag?and?Drop?List?Control 程序运行效果截图:  这篇文章包含一个demo project，一个继承于CListCtrl的类和一个快速查看这个类功能的release。我不想让这个类十全十美，但对于我当前的项目来讲，它的功能已经足够了。当然了，它还有更进一步完善的地方，欢迎指正！ 左图是程序演示的示例图片。 类CDragDropListCtrl具有以下的功能和特性： 1、支持单选和复选的任意托拽 2、所选择的托拽目标跟随这鼠标突现式的移动 3、当把目标托出上下边界的时候，List Control会自动滚动 4、以LVS_EX_FULLROWSELECT风格的开关方式运行、 5、保存所托拽目标的状态 6、所有的代码都封装在control当中－无需修改父类 本类源自Wayne Berthin以前写过的一篇文章，但我重写了大部分代码，并且又增加了很多。CreateDragImageEx 方法跟Frank Kobs所给 出的大致相同，但修复了一个小的bug以便于程序能更好的运行。 要使用这个类，首先要把DragDropListCtrl.cpp和DragDropListCtrl.h两个文件添加到你的工程当中，然后在你的对话框资源中增加一个 List Control，并设置View方式为Report，用ClassWizard为这个List Control添加一个变量，变量的类别为Control，变量类型为 CDragDropListCtrl，最后，把下面一行加到你的对话框头文件的顶部： #include DragDropListCtrl.h 这样就大功告成了！ MFC窗口位置管理详细分析及实例在一般用MFC编写的程序的窗口客户区中，可能有好几个子窗口(具有WM_CHILD风格的窗口)。上边是工具栏，中间是视图窗口，下边是状态栏。三个窗口在框架的客户区里和平共处，互不重叠。主框架窗口的尺寸改变了，别的子窗口都能及时调整自己的尺寸以便保持相互位置关系不变，例如状态条窗口总能保持在主框架客户区底部，并且其宽度总能和主框架客户区宽度一致。工具栏窗口总能停靠在主框架的某一边不变，其宽度或高度总能和主框架客户区的宽度或高度一致，视图窗口总能填满主框架客户区的剩余空间。 假如我们自己从CWnd类派生一个窗口类并生成一个窗口，在它的客户区里要生成若干个子窗口，我们想使这些子窗口排列得规规矩矩，互不重叠，当父窗口的尺寸变了时各个子窗口能适时调整自己的尺寸和位置，使各个子窗口之间的位置大小比例关系不变。当移动其中一个或几个子窗口时，别的子窗口能及时为这个移动了的子窗口让位。当然我们可以利用api函数里管理窗口的函数来编写自己的管理子窗口的方法。可是如果在父窗口的客户区里有了工具栏，状态条等等子窗口时，你自己加进来的子窗口还能和这些mfc提供的子窗口融洽相处吗？你如何保证你的子窗口不会覆盖了能够四处停靠的工具栏？当工具栏和状态条消失后你的子窗口如何才能知道，以便及时调整自己的大小从而覆盖工具栏和状态条腾出的空间？基于文档视图构架的窗口的客户区内还有个视图，你自己硬加上的子窗口能不和视图窗口争地盘吗？ 所以必须了解mfc的窗口管理它的客户区的方法。其实，mfc的窗口管理它的客户区的方法是非常简单的：父窗口调用一个函数，子窗口响应一个消息，就这么多。 CWnd::RepositionBars函数和WM_SIZEPARENT消息 先简述一下mfc的窗口为子窗口分配客户区空间的过程：这一过程是父窗口与子窗口共同协调完成的。父窗口先提供它的客户区内的一块区域，叫做起始可用区域。然后调用一个函数，在这个函数里，父窗口把这片区域通过一个消息提交给它的第一个子窗口，该子窗口决定自己要占用多大一块，然后在可用区域里把它将占据的部分划出去，这样可用区域就被切去了一块。父窗口再把这块剩下的可用区域通过同样的消息提交给第二个子窗口，第二个子窗口再根据自己的需要切掉一块。如此这般，每个子窗口都切去自己所需的一块。最后剩下的可用区域就给最后的子窗口使用。可以看出，除了最后一个子窗口外，其它子窗口都得在消息响应函数里有自己的算法来决定自己将在可用区域里占据多大一块，最后一个子窗口由于别无选择，所以不需要这样的算法。 当然，初始的可用区域是一个矩形，每次被切割后剩下的可用区域还是一个矩形，不可能是别的形状的。 举例说来，在一个典型单文档程序中，父窗口就是从CFrameWnd派生的主框架窗口，最后一个子窗口就是视图窗口，如果用了CSplitterWnd生成分隔条的话，最后一个子窗口就是拥有分隔条的那个窗口。其它子窗口就是工具栏窗口和状态条窗口，以及可能有的别的控件窗口。 在典型多文档界面程序中