[Lazarus] Decision required WRT dragging
DrDiettrich1 at aol.com
Thu Mar 29 23:24:35 CEST 2012
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.
More information about the Lazarus