[Lazarus] Generalized DragDrop

[michael.vancanneyt at wisa.be]

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

> Michael Van Canneyt schrieb:
>
>>>> 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.
>
> Please specify what "non-trivial" use you have in mind, and what results you 
> expect to see in this very early implementation stage (proof of concetpt).

Drop a piece of text from wordpad on a TMemo. The text should be inserted at
the drop point.

>>> 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.
>
> Not only information, but also functionality!
>
>> That is what it is for, and it is also the recommended practice in Delphi: 
>> creating a descendant of TDragObject for specific purposes.
>
> Right, and every such Delphi class reacts on dragging events, in its 
> ProcessMessages method.
>
>
>>> 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.
>
> You miss the really essential point: the interface between the drag manager 
> and the drag object.

I am not missing anything, I am just saying that putting everyting in the
base drag object is not a good decision. I'm not interested in the
implementation details such as dragperformer and whatnot.

I'm interested in how the end-user (the application programmer) sees DnD.
Namely: he can re-use his existing knowledge, there are simply some extra
descendants of TDragObject that implement external file DND and
Inter-application DND, all the rest goes through the same events/methods 
that exist now.

How this is accomplished in the background is not so relevant to me; I'm
sure that the people involved will solve it in any way they see fit.

Michael.