[Lazarus] Decision required WRT dragging

[Hans-Peter Diettrich]

Paul Ishenin schrieb:
> 29.03.12 20:30, Hans-Peter Diettrich wrote:
> 
>> Some "bugs" cannot be fixed in code. E.g. when a form or control is
>> docked in code, what should happen to its DragKind? When the DragManager
>> requires a properly initialized DragKind, in order to start the proper
>> operation, should the property of the control be changed, or should we
>> introduce distinct calls that would allow to dock non-dockable controls
>> programmatically? The patch here checks for an already set HostDockSite,
>> which definitely indicates that the control *is* already docked, and
>> adjusts the DragKind accordingly.
> 
> The code which manually dock something in IDE should check the DragKing. 
> Nobody except the developer should change this property, especially not 
> the DragManager.

So what should happen in such a case, where the developer didn't observe 
the rules? Should it be considered a fatal bug, and raise an exception?

In the IDE case it's perfectly allowed to change the DragKind, because 
it's what the developer had in mind.

>> For the second problem, the illegal change of the mouse capture, what
>> should we consider as the reason for such bugs, and how to cure it? This
>> can be solved in two ways:
>>
>> 1) The DragManager ignores such changes.
>> 2) The "dragging" state is checked in the control, before an attempt is
>> made to change the capture.
> 
> You need to find the control which changes the capture diring the drag 
> and fix this control code.

What do you need more than setting an breakpoint?

When all these bugs have been fixed, the DragManager.CaptureChanged has 
nothing to do any more - that's exactly what the patch does right now.

DoDi