[Lazarus] Generalized DragDrop

[Hans-Peter Diettrich]

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).


>> 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.

The LCL implementation has *added* a dragmanager object, that is 
*restricted* to internal dragging. Why that bloat?

The LCL implementation has *removed* message processing from 
TDragObject, and instead has *added* sealed DragPerformers. Why that bloat?

This castration disallows to implement further dragging models in 
TDragObject descendants. How else should this be done, then???

This is what I call "totally wrong design" :-(

> The API is there. It is extensible - all we need to do is use the 
> already-provided mechanisms.

So you agree to add the removed methods to TDragObject again? ;-)

DoDi