[Lazarus] Generalized DragDrop

Michael Van Canneyt michael at freepascal.org
Sat Jan 22 16:04:34 CET 2011



On Sat, 22 Jan 2011, Hans-Peter Diettrich wrote:

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

> Why that?
> - A more general approach could solve the known problem with docking forms, 
> by including dragging by the window manager.
> - Drag-drop of files or other objects as an alternative to an OpenDialog.
>
> - Embedding of shared objects (COM, CORBA...)
>
> What's required?
>
> - A generalization of the DragManager, so that visual (DragImage...) and 
> application feedback (events) are not restricted to application-internal drag 
> sources and implementations. This is not hard to do, all that can be handled 
> in the already existing or added specialized DragObjects, instead of the 
> (superfluous) DragPerformers.
>
> - A DragObject should include a SourceType property, so that the targets can 
> handle more source types, e.g. filenames or COM/CORBA objects, in addition to 
> controls. Mime types (strings or enum) can be used for that purpose. Further 
> information for inter-process dragging can be added (source PID, HWND...), so 
> that an application can distinguish internal references (to controls...) from 
> references to objects in other processes.
>
> - The event handlers must have access to the extended source information. 
> This is also no problem, since only one drag operation can be active at any 
> time, so that a global DragObject reference can be used everywhere. A 
> predefined DragObject can be used whenever an external object is being 
> dragged over an application form.
>
> - More drag and drop types should be defined, in addition to "drop" and 
> "dock", e.g. "open files", "link" or "embed". Eventually specialized drag 
> targets must register themselves, for e.g. accepting files or embedding 
> objects, in addition do DockSite registration.

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.

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 don't like the idea of SourceType as a general property. I would make it an enumerated
(stInternal,stFiles,stExternal) and the TExternalDragObject object can have a MimeTypes property.
The TFileDragObject can have a 'FileNames' property of type TStrings; it's all it needs.
Putting everything in the base class is IMHO not necessary, and only complicates things.

Michael.




More information about the Lazarus mailing list