Hi Viv,

Thanks for the reply. Yes, I think I'll try your suggestion, using OLE drag-and-drop. I had some concerns about the complexity of this, but the more I think about it, the easier it seems. There may be a little more to it than what you mentioned, though. Supporting a clock-based auto-drag threshold seems like a potentially useful refinement, to deal with very small displacements and dead-edge effects. But this is secondary, and not terribly difficult.

My greater concern has to do with very flaky behaviors I've seen with and without NODEFAULT statements in some of these methods. That makes me leery of adding anything unnecessary into mouse-related event logic, but I guess I'll just have to cross that bridge when I come to it. Thanks again for your advice.

Mike

>Hi,
>
>Using the VFP Drag it's best to control this yourself using Manual dragmode. The usual approach is to capture the current coordinates in the MouseDown() event then initiate the Drag() in the MouseMove() event when the current coords are regarded as significantly different. There are examples of this around but I have no references to hand.
>
>Presumably the same approach could be applied to OLEDrag.
>
>HTH,
>Viv
>
>>>
>Has anyone noticed that VFP's automatic OLE drag mode tends to kick in too quickly? This occurs whether I set OLEDragMode = 1 (Automatic), or if I use OLEDrag(.T.), which is only supposed to initiate the drag "after the user has pressed the mouse button for a sufficient period of time to indicate that a drag operation is occurring, or the mouse is moved a sufficient distance while the mouse button is pressed". Is there any way to adjust the parameters that govern this, e.g. via some registry settings?
><<
>+