In accordance with MSDN the only correct place for installation of custom cursor for drag operation is IDropSource::GiveFeedback callback. Additional attempts to change the cursor form will lead to cursor blinking at the beginning of drag operation.

The problem is that OLE internally loss the custom cursor just after installation and change it to system form in case of “no-drop” operation (mainly inside drag-source window, but not only). As a result in Java AWT we got at least one CR as a result of workaround.

The example for this bug is in attachment. It is required MFC library for compilation and running. Steps to reproduce:
1. Unpack attached native MFC application.
2. Compile it in release or debug mode (or just run existent DnDCustomCursorTest.exe)
3. Press left button under the label to start drag operation. The cursor will blink from custom to system form (that is a problem).
4. Drag cursor out from dialog and return back. The custom form will conserved. But any movement over the dialog caption or text field will change the cursor form to system default for “no-drop”.
5. Note! The sleep in GiveFeedback is used just to make blink visible on fast computers and prove that custom cursor form was set.

Acceptance criteria:
The form of custom drag cursor conserves between IDropSource::GiveFeedback calls (if there are not active drop target clients).