[Lazarus] What are "widgets" in lazarus?

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:

>> As mentioned above, *every* dragmanager must have handles for all 
>> involved components. An OS-wide dragmanager can only use OS-wide 
>> handles, e.g. those of the OS-wide window manager.
> 
> Lets take Windows OLE drag-n-drop protocol as an example. It needs the
> window handle of the component (eg: TEdit) that can accept a drop.

So what? If somebody *wants* to allow OLE drag-drop for a component, he 
must choose an appropriate one (here one with a HWND, or some other 
OLE/COM object).

If you want such dragging for a single pixel, you must wrap that pixel 
into an container that supports dragging. Drag-drop does not come at 
zero cost.

> Irrespective if it is a drag-from-component-to-component-inside-same-app
> or a drag and drop from one app to another. In Qt 4.4 and later, such an
> Edit component doesn't have a windows handle any more, so OLE can't talk
> to that Edit component. The only OS window handle is the top-level form.
> Trolltech had to implement some serious black magic in Qt to still work
> with OLE DND - yet no difference to the end-user. This is what I'm so
> impressed with, and have no real clue how they accomplished that (yet).

I cannot see any black magic here, even if it may sound like that to 
marketing people. When the OLE dragmanager needs a HWND, for sending 
messages to a source or target, any such HWND is sufficient. The 
receiver of the message can determine a more specific source or target 
at will, i.e. allow for an drop inside a window only, when the 
coordinates match a specific control inside that window. The Lazarus 
dragmanager does this already.

If nothing helps, the application can create a temporary invisible 
window, or any other applicable OLE object, on top of the target 
control. This object then can be moved to every possible target control, 
that resides at the current mouse position. But this is not a necessary 
requirement at all, when the screen position of the target area is 
explicitly stored in the OLE object. There exist more components, like 
timers, that have no visual representation at all, but have a HWND for 
communication purposes.

> XDND protocol works very different to Windows OLE DND, but still X11
> window handles are required for the component which is the source or
> target of a drag-n-drop action, including the top-level window handle so
> as to communicate with the other app or component.

So that's not really different from any other (Windows...) d&d.


> And when I say drag-n-drop, I mean full DND support. In app
> drag-and-drop (component to component in same app) and application to
> application. XDND even allows computer-to-computer DND.

What does dropping mean other than a notification (message...) to the 
target (handle), that a source (handle) has been dropped onto it?


> The DND support Delphi has in the VCL is a joke, and hardly what I would
> call real drag-n-drop. It's just one component inside the same app
> sending a message (or executing an event) on another component in that
> same app.

Sorry, that's nonsense :-(

You should understand VCL/LCL dragging first, before you make wrong 
assumptions about different operation and requirements of other drag 
managers.

It were no problem to extend the LCL dragmanager to inter-process 
dragging. But since there must exist conventions, how a target window of 
*any* application will signal acceptance of an possible drop, and will 
handle the drop, and will handle the dropped source (residing in another 
process), it's a much better idea to use the existing OLE d&d 
conventions for *that* purpose.

You also should understand that Delphi d&d is not limited to source 
controls (Lazarus missed that aspect a bit), so that the TDragObject is 
equivalent to an OLEDragObject, only with an different set of methods 
and properties.


> Any app-to-app DND, and you are on your own (outside the scope
> of the VCL), and you have to resort to Win API calls or implement your
> own full OLE DND implementation.

Right, because a process needs some OS support, for communication with 
other processes. That's nothing new, isn't it?

And when OLE d&d requires HWNDs, that's a justficiation for another LCL 
d&d, that comes without such heavy requirements.

DoDi