事实上，在测试上一篇代码的时候就有发现这个问题，当时给了自己一个“这是客户端运算响应瓶颈”的借口，就得过且过了。但被几位点破，令我多少有些羞愧，于是重新审视iGoogle页面，发现在移动较快的时候，也有模块“卡住”的情况，但片刻之后又跟上了鼠标的移动，并没有出现“掉队”的结果。思考之后，得出结论，iGoogle也许是从全局而非被拖拽控件本身来考虑拖拽行为的。于是重新编写代码，于是又有了新的Demo：

这次各位可以随便拖拽方块，怎么快都可以，只要鼠标不超出Silverlight的范围（黑色边框）。

首先考虑三个事件：

拖拽的全过程中包括三个事件：MouseLeftButtonDown(左键按下),MouseLeftButtonUp（左键抬起）,MouseMove（左键移动）。上一篇文章中的做法是三个事件全部属于DragableGrid。虽然从逻辑上考虑没有问题，但实际操作中，由于鼠标运动过快，可能会脱离DragableGrid，使其无法处理鼠标事件；而另一方面，在拖拽过程中，无论鼠标如何移动，是不会离开拖拽的场所，也就是最外层的Grid容器的范围的。所以现在只给DragableGrid保留了MouseLeftButtonDown事件，因为只有鼠标点击到DragableGrid上才会开始拖拽行为，而MouseLeftButtonUp与MouseMove则放在了Grid上进行处理。

重新架构代码：

之前的代码DragableGrid和ShadowGrid耦合度极高，基本上是我中有你，你中有我。而考虑在拖拽场景中，拖拽实际上影响的只是控件的定位、顺序，而与控件本身的行为、样式以及功能逻辑没有任何关系。那么与其把控制定位的代码分散在各个控件之中，不如用一个统一的管理器来调度控件的拖拽。而且拖拽的特点是：同一时间只可能有一个控件被拖拽，那么用静态的管理器或者单件就是很顺理成章的了：

static public Panel ContainerGrid;
static public List<Panel> ContainerPanels;

static private FrameworkElement _draggingGrid;
static private Grid _shadowGrid = null;
static private bool _isDragging;

/// <summary>
/// 鼠标拖拽起始点（相对于被拖拽的控件）
/// </summary>
private static Point _beginPoint = new Point();
private static int _hIndex = 0;
private static int _vIndex = 0;

除了因为需要外部设定而设为公有的ContainerGrid和ContainerPanel，其余的都是在管理器内部调用的用于实现拖拽逻辑的私有成员。而且由于所有拖拽逻辑的实现都在管理器内部，而对牵涉到的控件并没有任何要求，所以这里表示容器的ContainerGrid、ContainerPanel以及表示正在被拖拽的控件的_draggingGrid，我都使用了最基础的类型。

其余的代码和上一篇类似，只是把它们从DragableGrid和ShadowGrid中提取出来，移到了DragManager中，这里不再赘述。

源代码下载：改进的可拖拽Silverlight控件源码