I guess that internal LCL controls are somehow based on something platform specific anyway (i.e. GTK+/GDK provides canvas, Win32 provides canvas), so we could look whether the DnD is supported on that canvas level.

This way, all custom controls would inherit the DnD features from canvas / TCustomControl / TGraphicControl, and the support would be transparent.

Just my theory,

Michal Bukovjan

Exactly my thoughts, I second that.
Method 2 is the best one, I think.

Michal Bukovjan

I think it had better be Method 2. Both GTK and Qt have come to an understanding of their implementations of DnD. Method 1 would make the DnD part of the LCL and not dependent on a widget set but totally break inter-application communication. We must be sure that the DnD can operate outside of the application built with FPC/Lazarus. By using the GTK/Qt DnD feature we can be sure that dragging outside of our application to another application can be handled. Also if you look at some of the ToDo list items with regards to GTK 1.4 they will be adding more features dealing with DnD. Let's let the widget set handle it so when those added features become available any existing Lazarus application will be able to use them with not further work on our part.

Now I just talked about our dragging out to another application. We also want to be sure that other applications can drag to ours. In other words we better be able to recognize a drop from another applications. Using the GTK/Qt DnD built in features will allow us to do just that.

I beleive the first way would be "easier" to port to other interface. tracking the mouse only involve "lcl" code, whereas the second one is based on the "gtk" way (underlying).

my 2 bits

OK, I want to start this discussion on Drag and Drop before coding it.

My idea's on how Drag and Drop can be implemented.

Method 1: By tracking the MouseMOve and MouseDown and MouseUp messages we can implement drag and drop within the LCL. When the Mouse Button is pressed and a move occus we set a global "Dragging" flag along with a "draggingcontrol" flag or something to track within what control the dragging began. If the mouse button is lifted and the mouse is within a control other than the "draggingcontrol" control then we know they are attempting to do a drag_drop. This is a very simplified explanation.

Method 2: Starting with GTK, it is already built into the widgets. So, when dragging begins a signal occus "drag_start" (or something like that). We can set up message methods

Procedure DragStart(var msg TDragMsg) ; message LM_DRAGSTART;
Procedure DragStart(var msg TDragMsg) ; message LM_DRAGDROP;
Procedure DragStart(var msg TDragMsg) ; message LM_DRAGMOVE;

and track the dragging there. Each widget sset would have to handle the dragging themselves. This would be the easier of the two as long as the widget sets each support certain things like these "drag messages" and such.

What is everyone's thought? I have implemented it both ways so far. The first is quite a bit more involved but it's similiar to the method used in Delphi. However, that's not needed in this case. By remaining similiar to Delphi in this case gains us nothing so that should not be a deciding factor.

Thanks
Shane

Just thinking of the following, how is it handled in delphi. Not all controls are system widgets, so how is this working.... You cant DnD a control to another application ???

I've tried to find it in the help but couldn't find something. Somewhere I remembered delphi has two ways of DnD.
One is the internal DnD (begindrag enddrag) this is out method 1 Another is the inter application Dnd, I thought is was called OLE-DnD, but couldn't find it and this is more method 2.

Our case is similar not all LCL components have a widget so they need metod 1 other witgets already have a buildin support.

I think we should find something which works transparent in both ways. I don't feel for a solution completely depending on the underlying platform and I tend to method 1 for LCL internally while using method 2 outside LCL. I'll have a closer look to find out if my statements are crap, but hthats after thost )@$(@ makefiles.

Marc

With Delphi, the object which is actually dragged is by default the control where the drag operation has been initialized, but can also be another TObject descendant. This can be usefull when different controls can be the sources of the same type of Object. In this case, the target control have only to care about one type of dragged object, and not all the possible (control) sources.

So an event like "GetDraggedObject" would be usefull. By default (if not implemented), it's the control itself, but it could be any other TObject descendant.

Hubert.