Re: Re[2]: [Foxgui-users]Error in Drag and Drop under Windows ??

[Jeroen v. d. Z. <jv...@cf...>]

On Friday 13 September 2002 12:01 pm, you wrote:
> Hello Jeroen,
>
> Friday, September 13, 2002, 5:21:36 PM, you wrote:
>
> JvdZ> The DND_ENTER and DND_LEAVE don't have any coordinates at this point;
> JvdZ> it simply indicates entering or leaving the widget.
>
> That's okay, but i also get wrong coordinates at SEL_DND_DROP. Is this
> the defined reaction ?
> I can simply take the coordinates from the latest SEL_DND_MOTION but
> can i rely on the fact that there is at least one move operation
> before i get a SEL_DND_DROP ?
>
>
> Best regards,
>  Lothar                            mailto:ll...@we...


Lothar,

(1) You get at least one SEL_DND_MOTION, because one is sent right after
   entering the window.

(2) The motion events are only sent when the status message from the drop
    target have been received.

(3) SEL_DND_DROP also does not contain any coordinates.  

The drag source and drop target are "loosely" cooperating, in the sense that
the drag source at no time assumes that the drop target is responsive, or even
alife.  A few messages (SEL_DND_ENTER, SEL_DND_LEAVE) are always sent, as long
as at least the window of the drop target exists.  SEL_DND_MOTION is sent right
after the initial SEL_DND_ENTER, and on each subsequent time, the SEL_DND_MOTION
is only sent after receiving a SEL_DND_STATUS from the drop target; no further
SEL_DND_MOTION messages are sent until another SEL_DND_STATUS is received.

Thus, if the target is unresponsive (dead) we won't end up filling up event queues.

The actual mouse position and the one that the drop target receives may be slightly
out of whack, because PostMessage() is used on Windows (we have to because SendMessage() 
is synchronous and that would cause the drag source to block, possibly indefinitely, for 
a unresponsive or dead drop target) and therefore some time may elapse between the
drag source posting and the drop target receiving the message.

Note:- SEL_DND_DROP does NOT contain any coordinates.  You already know why:- the
drag source's decision to drop or not to drop was based on the last CONFIRMED position
sent to the drop target, and the last status message received from the target based on
this last position message.

Sending a newer position in the SEL_DND_DROP would mean that the drop target would receive 
a drop in a different spot that the one confirmed to the sender:- possibly an unintended 
drop spot!



Hope this explains a bit.


		- Jeroen