[Lazarus] Generalized DragDrop

[Michael Van Canneyt]

On Sun, 23 Jan 2011, Hans-Peter Diettrich wrote:

> Michael Van Canneyt schrieb:
>
>>> In fpGUI Graeme implemented an interface for inter-process dragging. It 
>>> would be nice to have a similar interace in the LCL, that extends the 
>>> current intra-process dragging.
>> 
>> While it is correct that Graeme did this, I still have not seen in action.
>> i.e. I have used the application-specific DnD, but I wouldn't know how to 
>> handle the intra-app DnD.
>
> Simply start the demo app twice, then drag...

I was thinking about something non-trivial, of course.

>> I'm all for it. Although I'm not sure that this can be implemented in a 
>> cross-platform way.
>> 
>> On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, 
>> there is no such thing, and I think it depends on the used desktop software 
>> (KDE vs Gnome).
>> I don't know how it is done in Mac.
>
> I think that Graeme can answer this question...
>
>
>> But your suggestion is at least a step in the right direction.
>> 
>> I would implement support in 2 objects: TFileDragObject (external files, as 
>> dropped by file managers)
>> TExternalDragObject (external app DnD)
>> Both are created whenever an external DnD is found.
>
> I'd leave all that to the concrete implementations, and provide specialized 
> handlers in the target controls. Currently TControl.DoDragMsg dispatches the 
> messages to the Drop and Dock methods, based on the DragObject class type. 
> More handlers can be added, and dispatch may be rebased on a drag type (enum) 
> property.

I don't think more handlers should be added. There are too many handlers already.
That is why you can put the extra information in objects which descend from TDragObject.

That is what it is for, and it is also the recommended practice in Delphi: 
creating a descendant of TDragObject for specific purposes.

>> Putting everything in the base class is IMHO not necessary, and only 
>> complicates things.
>
> The base class (TDragObject) only must declare the extended API, including 
> common properties.

No, that is IMHO a totally wrong design, which will make the base object unnecessarily 
heavy. This is exactly the reason why the API allows you to create your custom drag 
object when a drag operation starts: to avoid putting everything in the base object.

The API is there. It is extensible - all we need to do is use the already-provided mechanisms.
It will require no changes to the code as it is, and the user need not know any extra handlers.

Michael.