Thanks for looking into that,
I've had a play, and although I think it might work, It all feels very 'hacky' to me.
Firstly, there's no drop caret - when you move the mouse during the drag (e.g. in notepad++) you get an extra little caret to show you where the text would drop if you let go and using this approach I'd need to overdraw my own to achieve the same effect,
Secondly, recalculating the paste position for a move is a headache, because as soon as you delete the currently selected text the paste position moves, so the new position would have to re-calculated.
All this is very doable, but it's a bunch of work, and it just feels like we're re-inventing the wheel.
I had a look in the Scintilla.Net source and in Scintilla.cs tried commenting out this section: (line 1105)
// The Scintilla native control kindly registers itself as a target of OLE drag-and-drop operations,
// however, that prevents us from doing the same. Unregistering it prior to calling base.OnHandleCreated
// will re-register us according to the AllowDrop property and we'll get support for the Drag events.
This was interesting - with this removed none of the scintilla.net drag drop events fired at all, which is as the comment suggests.
However now that the native control is servicing drag and drop, click-drag now magically works!
Also, so does dragging text to and from other controls within my app, and external apps including np++ and word.
So on the face of it this solves my problem, except it doesn't, because I now have a non-standard version of scintilla.net :(
Could calling 'RevokeDragDrop' be made optional?
It's also set me thinking - why does scintilla.net even need it's own drag and drop interface if the underlying scintilla control is already servicing the events?