[Lazarus] Generalized DragDrop
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Sun Jan 23 22:22:24 CET 2011
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
More information about the Lazarus
mailing list