Custom drop formats for Windows...

[Anders Karlsson]

I want to add a way to support custom drop formats to Scintilla. This
is, I think, mostly relevant on windows. I see a need to add five
things for this:
- Members for the custom clipformats in the ScintillaWin class
- A new message that allows me to set these (tow arguments: a count
and a pointer to an array of formats).
- ScintillaWin::DragEnter must check for these formats.
- ScintillaWin::Drop needs to check the custom formats first, and send
a notification to the parent (arguments: the format, the handle (I
think only supporting TYMED_HGLOBAL is a reasonable simplification
here) and the point where the drop occured). The reason we want the
point of the drop is that the parent might want to pop up a menu to
select the action. The parent does it's work, and returns telling if
something was done, and if so, the text of this is dropped in a
handle.
- Additions to SCNotification

The complex part is the drop, but not even this is terribly complex.
The outcome of the call to the parent may be three different things:
- The drop wasn't handled by the parent, so Scintilla may try with
CF_TEXT / CF_UNICODETEXT.
- The drop was handled, so Scintilla should process the text in the
handle passed back.
- The drop was handled, but there is nothing for Scintilla to do (say,
a File was dropped, and a menu poped up, and the user can choose
either to paste the text of it open the file in some other window. In
the last case, this is not an error, but there is nothing for
Scintilla to do anyway).

What do you say? I have sterted playing with this, and it doesn't
seems like it will be overly complex. Being able to drop a file and
pasting the contents into Scintilla is pretty useful.

There are other ways of achieving this, the most obvious is to have
the parent handle this. But the problem with this is that it breaks
some of the stuff that SCintilla does to handle text dragging and
dropping, in particular when dragging within Scintilla itself.

/Karlsson

[Neil Hodgson]

Anders Karlsson:

> I want to add a way to support custom drop formats to Scintilla.

> ...

> - The drop was handled, but there is nothing for Scintilla to do (say,
> a File was dropped, and a menu poped up, and the user can choose

If you want access to file dropping, this is not the standard
supported way to do it.

SciTE supports file dropping through the DragAcceptFiles API and
subsequent WM_DROPFILES message.

Neil

[Anders Karlsson]

I am aware of this, and this is how I handle dropped files in MyQuery
right now. But relying on WM_FROPFILES has a few limitations here:
- I don't get to know the state of the mouse buttons, or specifically, I
don't know if this is a right or a left button drag. In the former case,
you want to pop up a menu or something, in the latter, the default
action is taken.

- I can only handle CF_HDROP drops, or file drops from say Explorer,
that is. For internal formats that are being dropped (that I want to
support here also), I can work around this by using a CF_HDROP format,
but at the same time keep track of what I am dropping inside the
application. The disadvantage with that W/O is that really I should put
some valid file content in the drop handle anyway, as the CF_HDROP
format may also be dropped anywehere else, outside my application. But
again, I can do this by creating a temp file, writing the data to be
dragged to that, and use that. Not elegant, a distinct kludge, but workable.

- I don't get Scintillas internal cursor to follow the drag operation.
Which in some cases is fine. In SCiTE, a drag will always open the file
in a new tab. But if you want to have the option in SciTE to, on a right
drag (and in SciTE and right and a left drag are the same, it seems,
probably for the reason mentioned above, WM_DROPFILES will not tell you
what it is), pop up a menu, to allow the user to insert the file
contents inito the current document, or open a new tab (this is exactly
what I am looking to do), in which case I *do* want the internal cursor
(what I mean with "internal cursor, or actually caret, it is the thing
that follow a CF_TEXT / CF_UNICODETEXT drag in Scintilla be it an
internal or external text-only drag).

So all in all, I agree that WM_DROPFILES is enough in many cases, but
what I am proposing is something that will

Cheers and thanx for all the good work on Scintilla, sofar I have had
very few things in SCintilla limitiing what I try to achieve with
MyQuery, and Scintilla also goves me quite a few more things to work
with in future releases.
/Karlsson
> Neil
>
> >
>

--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Anders Karlsson (and...@mysql.com)
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Sales Engineer
/_/ /_/\_, /___/\___\_\___/ Stockholm
<___/ www.mysql.com Cellphone: +46 708 608121
Skype: drdatabase

[Neil Hodgson]

Anders Karlsson:

> I want to add a way to support custom drop formats to Scintilla. This
> is, I think, mostly relevant on windows. I see a need to add five
> things for this:

I'd like to be sure that this was going to be sufficient before
inclusion. When even more functionality is needed, the end point will be
taking over from ScintillaWin's IDropTarget interface completely. In
which case there should be a call to get the current IDropTarget
interface after which RevokeDragDrop and RegisterDragDrop are called to
use the container's IDropTarget. There could be a call to position the
drag caret although that could also be achieved through calling the
original DragOver.

> - Members for the custom clipformats in the ScintillaWin class
> - A new message that allows me to set these (tow arguments: a count
> and a pointer to an array of formats).

To accommodate multiple container languages, arrays are frowned on
unless really necessary. A message to add a format would be more consistent.

> The parent does it's work, and returns telling if
> something was done, and if so, the text of this is dropped in a
> handle.

In Scintilla notifications do not return any form of response code.
The preferred mechanism is to send a message for the exceptional case
which here is probably to abandon default handling of the drop.

The case where the container wants to intercept drops of text should
be considered.

Neil

[Anders Karlsson]

Neil!

Many thanx for the reply. As for now, I have implemented this in an
upcoming MyQuery 3.1, without modifying Scintilla. It works OK, but it
is a bit messy as I have to deal with OLE objects in the windows I drag
from, and then deal with WM_DROPFILES for dropping of files. The
non-pleasant aspect of this is that the look of dropping a text object
and a file is different (standard drop icons vs. the Scintilla drop caret).
I does work though. For the custom objects I am dropping, where I
would like to contain multiple different text objects, and bring up a
menu to select which (these are compond objects), I decided to skip this
for now.

As for your suggestions and ideas, I agree (I'm no fan of arrays
either, it was just that they are used in the current Windows DnD model
that I wanted to mimic. Also, it seems that when you register a target,
you need to provide the supported formats, I have not seens a means per
se of adding formats later, but that can probably be handled anyway).
I'll experiment a bit, using your suggestions, eventually, and see where
I wnd up.

Cheers and many thanx.
/Karlsson

[Neil Hodgson]

Anders Karlsson:

> Also, it seems that when you register a target,
> you need to provide the supported formats, I have not seens a means per
> se of adding formats later, but that can probably be handled anyway).

You register an IDropTarget. It is called for each drag so the set
of formats that can be accepted can change over time.

Neil

[Anders Karlsson]

Ah. Right, of course. I had mostly been looking at the OLD docs, but
when looking at the implementation, I see what you mean. No big deal
then! Then I buy into your solution of course, much neater with a
message to add a format!

Cheers
/Karlsson