#926 Incorrect drag-drop handling

Scintilla (796)

On Windows, if you set *pdwEffect to DROPEFFECT_NONE and return success from ScintillaWin::DragEnter, it will be impossible to drop a file (not a text) on the parent window. If you return failure (E_FAIL) without modifying *pdwEffect, drag-drop will be forwarded to next window in the chain.
Please apply the second case.


  • Neil Hodgson

    Neil Hodgson - 2010-03-05

    Dropping a file onto SciTE works fine.

  • Neil Hodgson

    Neil Hodgson - 2010-03-05
    • priority: 5 --> 3
    • assigned_to: nobody --> nyamatongwe
    • status: open --> open-works-for-me
  • sapero

    sapero - 2010-03-05

    dragdrop extension with autoscroll

  • sapero

    sapero - 2010-03-05

    Scite uses the easiest way: DragAcceptFiles, which gives you no control over the data. I meant when the parent window is registered dragdrop-target via RegisterDragDrop, and it has the Scintilla control, draggianga file from any shell window, moving the cursor (very fast) over scintilla, makes the drop effect to none, and the parent does not receive DragEnter. Sometimes you really need to use RegisterDragDrop, for example when an application can accept text files to just display them, and when you want to drop an executable directly on Tools menu to add it to menu.
    Anyway it still does not work correctly, even with this change. In my DragEnter handler I'm disabling scintilla window using EnableWIndow, so when the cursor moves over it, drop effect is nonzero. I think I need to implement something like GetDropTarget, sent to the parent window from ScintillaWin::DragEnter. Yup! it works for me, attaching ScintillaWin-dragdrop.cxx with modifications.

  • Neil Hodgson

    Neil Hodgson - 2010-03-06

    The patch looks complex to me and requires a particular undocumented implementation in the container. Using WM_GETOBJECT with an IID rather than an OBJID appears wrong - OBJID_NATIVEOM and then a QI would seem more compatible. Using SetProp to remember the interface to the container (as opposed to adding a member to ScintillaWin or calling WM_GETOBJECT each time) is weird and unexpected.

    I don't think its a good idea to include this in the current form. Perhaps an explicit SCI_SETUNEXPECTEDDROPHANDLER would be simpler.

  • sapero

    sapero - 2010-03-06

    Sure, the message choosen by me is wrong, but it was the first thing. For menu we have WM_MENUGETOBJECT, but no message is predefined for general purpose, except, like shell - use RegisterWindowMessage. This was a suggestion.
    The autoscroll feature is in alpha stage. Scrolling to left and right should begin after a small delay, because for now, when you drag text between two vertically tiled controls, the source control is always scrolling.

    I see the providing of additional droptarget (as you said) - as a SCI_SET/GET message, or sent only when it is really needed, in the form of an notification message.
    By the way SetProp and GetProp for general messaging or subclassing purposes it is fast enough. Some compilers use it natively, for example to store control colors, class pointers, or even event pointers, so GWL_USERDATA is free for the coder.

  • Neil Hodgson

    Neil Hodgson - 2010-03-08

    The autoscroll code should be a separate issue so that those that want to use one feature or the other can incorporate the appropriate code.

    Another problem with SetProp / GetProp is that this exposes the internals of ScintillaWin. Perhaps you want to be able to change the drop target by calling SetProp as well as by implementing WM_GETOBJECT but I couldn't see any reason to do so.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks