Explorer’s drag/drop effects include a little message information box as part of the drop effect. For example, it will start with the message Move to ⸢folder⸥, but if you hold the Ctrl key, the message changes to Copy to ⸢folder⸥. How can you get a piece of that action?
As we saw last time, the visual drag/drop feedback effects used by Explorer are available for general use, via an object know as the shell drop target helper.
Let’s take our scratch program and teach it how to add the fancy information box.
The information box is configured by the DROPDESCRIPTION structure which is associated with the CFSTR_ clipboard format.
#include <strsafe.h>
HRESULT SetDropDescription(
IDataObject* dataObject, DROPIMAGETYPE type,
PCWSTR message = nullptr, PCWSTR insert = nullptr)
{
wil::unique_hglobal_ptr<DROPDESCRIPTION> data(
reinterpret_cast<DROPDESCRIPTION*>(
GlobalAlloc(GPTR, sizeof(DROPDESCRIPTION))));
RETURN_IF_NULL_ALLOC(data);
data->type = type;
RETURN_IF_FAILED(StringCchCopyEx(data->szMessage, ARRAYSIZE(data->szMessage),
message, nullptr, nullptr, STRSAFE_IGNORE_NULLS));
RETURN_IF_FAILED(StringCchCopyEx(data->szInsert, ARRAYSIZE(data->szInsert),
insert, nullptr, nullptr, STRSAFE_IGNORE_NULLS));
FORMATETC fmte = { (CLIPFORMAT)RegisterClipboardFormat(CFSTR_DROPDESCRIPTION),
nullptr, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };
STGMEDIUM med = { TYMED_HGLOBAL };
med.hGlobal = data.get();
RETURN_IF_FAILED(dataObject->SetData(&fmte, &med, true));
data.release();
return S_OK;
}
We allocate a DROPDESCRIPTION structure as an HGLOBAL and copy the drop image type, optional message, and optional message insertion into the structure before setting the data into the data object.
You can read the documentation for DROPDESCRIPTION for details on how the message and message insertion interact. For this example, we’ll just use a simple message with no insertions.
struct SimpleDropTarget
{
...
STDMETHOD DragLeave()
{
if (dto) SetDropDescription(dto.get(), DROPIMAGE_INVALID);
dto = nullptr;
return helper->DragLeave();
}
HRESULT CalculateFeedback(
DWORD grfKeyState,
DWORD* pdwEffect)
{
if (grfKeyState & MK_CONTROL) {
*pdwEffect = DROPEFFECT_COPY;
SetDropDescription(dto.get(), DROPIMAGE_COPY,
L"Copy with awesomesauce.");
}
else {
*pdwEffect = DROPEFFECT_MOVE;
SetDropDescription(dto.get(), DROPIMAGE_MOVE,
L"Move with awesomesauce.");
}
return S_OK;
}
};
When we calculate the feedback, we also set the drop description to tell the user what will happen when the drop happens. We also clear the drop description (by setting it to “invalid” with an empty message)¹ when the user decided not to drop it onto our drop target after all. This ensures that our custom description doesn’t hang around and accidentally get shown for other drop targets that don’t set a description.
So there you have it, drag feedback done the same way that Explorer does it.
¹ There is no way to remove data from a data object, so the best you can do is replace the data with new data that says “Nevermind.”
Does each application get its own DnD instance or is there a global shared one? I've seen it get stuck on numerous occasions where for example, there is a ghost image of a file or folder stuck on the desktop and drag-and-drop no longer works and I have to jump through hoops to try to get Explorer to let me drag something again (which usually doesn't work at all until I restart it or reboot)....
Is it a requirement to use
GlobalAllochere?Yes. The documentation for CFSTR_DROPDESCRIPTION specifically defines the data structure as being an HGLOBAL, which needs to come from GlobalAlloc.
More specifically, the STGMEDIUM(storage medium) parameter is defined to hold TYMED_HGLOBAL, which the TYMED doc lists as
"The storage medium is a global memory handle (HGLOBAL). Allocate the global handle with the GMEM_MOVEABLE flag. If the punkForRelease member of STGMEDIUM is NULL, the destination process should use GlobalFree to release the memory."
I'm tentative about whether that requirement is actually enforced in Windows NT, because in the given code snippet (which implies ) is passed to , whereas accordingly requires . causes to return a pointer, whereas causes it to return an opaque handle, so if does work the way it is described, the given code should not work because the incorrect type of argument is passed.
GlobalAlloc is absolutely required and the example code is correct. Think about what the data object is going to do; GlobalLock, use data, GlobalUnlock, GlobalFree. The trick here is that GlobalLock on a fixed HGLOBAL is legal.
The bug potential is in custom data objects. If they forget to call Lock they will seem to work fine when given fixed memory but break when given movable memory.
See also: Search this blog for GlobalAlloc to find the...
Does that mean it's up to every application to associate semantics with particular modifier keys - they have to ask "is the ctrl key pressed?" and know the convention that ctrl means copy, rather than being able to ask the framework "is this a copy operation?"
That would seem to pose some interesting future-compatibility challenges: if the touchscreen UI wanted to adopt a convention that two-finger drag means copy[1], or a Minority Report style VR gesture-based...
The touch convention is that immediate drag is treated as left-click drag and tap-and-hold then drag is treated as right-click drag. Standard keyboard modifiers apply. If you're on a device without a keyboard, you're not out of luck, since all of the options available with modifier keys are typically (and required by the Windows UI design guidelines) also available on the context menu after a right-click drag.
Not every application has the same verbs for a...