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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
