A customer had a shell namespace extension and discovered that when the user dragged an item, their custom drop target gets DragÂEnter
and DragÂLeave
method calls as expected, but the DragÂOver
method calls are being throttled. Specifically, they get a new DragÂOver
call only if the keyboard modifier state changes. How can they get a DragÂOver
call for every mouse move?
Explorer calls the shell extension when significant events occur, such as the user dragging over a different item, but it doesn’t call out for insignificant events, like the mouse moving one pixel.
The customer explained that they found that the default drag feedback for shell extensions doesn’t match the default drag feedback used by Explorer. In particular, the little information box that says “Copy to…” or “Move to…” is missing. The customer wrote their own information box window to show that information, so they need the precise mouse location information so they can position the information box properly.
Oh, if it’s the information box you’re after, then you could have just asked for the information box. (Another case of an XY problem.)
Explorer uses the shell drag/drop helper, so you can use the SetÂDropÂDescription
function we wrote last time. That will put the information box next to the drag image in exactly the same way that Explorer does. (Because this is the same method that Explorer itself uses to put information into the info box.)
The customer was kind enough to write back. “It works perfectly.”
Could the customer, left to their own devices, have registered each pixel as a separate item in order to get the effect they were expecting?