Question: How does non-OLE Drag and Drop work?

[roytam1]

it seems that winfile is the only non-OLE Drag source that people can find legally, and it seems to be very complicated to me how it works.
There are some questions coming in mind:

• Who fires/triggers to fire undocumented window message WM_DROPOBJECT, WM_QUERYDROPOBJECT, WM_BEGINDRAG, WM_DRAGLOOP, WM_DRAGSELECT, WM_DRAGMOVE?
• What does undocumented API DragObject() actually do?
• Who is responsible to process object dragging is accepted by target window?

[malxau]

Firstly, thanks for all of your work on RetroZilla.

I tried to research answers to your questions, although the WinFile code here is the best documentation I can find. It attempts to describe the interface of each message, including the values of wParam/lParam and return values. What follows is a more high level description of the phases of the operation.

DragObject() is the function that implements the dragging state and sends most of the messages. It's where all of the business logic about what dragging means is implemented. Note the caller specifies the type of the object as well as a caller allocated buffer describing the object. This function accepts two window handles. The first is the window that limits the scope of the drag; any drag outside of this window's bounds will be rejected. The second is the one processing window messages and driving the operation. It looks like the first was intended for MDI applications to restrict dragging to within themselves (using the frame window), although WinFile also uses GetDesktopWindow() in one call site, which is effectively disabling any restrictions on where the drag can go. Note that the later Windows 3.1 Drag & Drop API (which is really only a Drop API) would have required no restrictions on the applications that the drag could go to.

WM_QUERYDROPOBJECT is the message that determines whether a window can accept a drop. It is sent to the childmost window, and progressively up the parent chain, until any window indicates it can accept drops. FALSE indicates not accepting drop; TRUE indicates accepting drop with a default cursor; or it can return a mouse cursor handle to use, which implies willingness to accept drops. There's an important piece of magic here, which is the list box control populates dwControlData with the item within the list box corresponding to the mouse location, before deferring to the parent to decide whether to accept the drop.

WM_DRAGSELECT is used to indicate that a drag has entered or left a window. It is sent to the window that the mouse is navigating over, with a wParam of TRUE if a drag enters a window, FALSE if a drag is leaving a window.

WM_DRAGMOVE is sent if a drag is moving within the same window, as an alternative to WM_DRAGSELECT. WinFile is able to use the dwControlData mentioned above to highlight the list item being dragged over. Note that because only one of these is sent for any mouse movement, WM_DRAGSELECT ends up needing to invoke the same logic as WM_DRAGMOVE.

WM_DRAGLOOP is sent after WM_QUERYDROPOBJECT but before WM_DRAGSELECT or WM_DRAGMOVE. It is sent to the window that initiated the drag, indicating whether the drag is over a window that is willing to accept a drop. This is used to allow the window to modify the mouse cursor, and that seems to be the sole reason it exists. Note this leaves an ambiguity because both the drop window and initiating window get a chance to set the mouse cursor - there's no clear ownership about which window is responsible.

WM_DROPOBJECT is sent at the end of a successful drop to the window that is receiving the drop.

WM_BEGINDRAG is the most interesting, and looks unused. All of the five above are sent from DragObject(), but this is sent from a list box control to its parent window when the list box detects a motion that should be interpreted as a drag. In WinFile, and in other software of the era, this is instead performed by WM_LBTRACKPOINT which is sent from the list box to its parent when the mouse is clicked on an item. WinFile implements the logic of WM_BEGINDRAG via a GetMessage() loop in response to WM_LBTRACKPOINT (and its implementation is much simpler.)

Does this answer your question?

[roytam1]

Firstly, thanks for all of your work on RetroZilla.

you're welcome!

I tried to research answers to your questions, although the WinFile code here is the best documentation I can find. It attempts to describe the interface of each message, including the values of wParam/lParam and return values. What follows is a more high level description of the phases of the operation.

(snipped)

Does this answer your question?

sure, it does help for implementing such mechanism in other project I involved (cross-referenced in RamonUnch/GreenPad#71 )
Thank you very much!