[Lazarus] Decision required WRT dragging
DrDiettrich1 at aol.com
Thu Mar 29 13:25:09 CEST 2012
Paul Ishenin schrieb:
> 29.03.2012 15:26, Hans-Peter Diettrich wrote:
>> 2) The example is too simple, it also works with a different DockManager.
>> Try again with a reasonable example, where the misbehaviour can be
>> observed, e.g. with the IDE.
> I believe you that IDE docking may behave wrong but why you put the
> responsibility to LCL and not to the drag manager which IDE uses? From
> my knowledge it does not the the docking manager from LDockTree.
Please don't make an DockManager responsible for bugs in dragging in
general. The erroneous calls, to capture the mouse while dragging is in
progress, are out of the responsibility and control of both DragManager
and DockManager. Instead of checks in every control, that captures the
mouse, a single check in the DragManager is better suited to block such
attempts. Herefore it's sufficient to ignore any calls of
DragManager.CaptureChanged, i.e. do nothing in that method.
> Frankly speaking docked IDE is not a priority for 1.0. Moreover we
> discussed this some time ago and decided to postpone the docked IDE to
> post 1.0 time because of complexity of topic and the amount of bugs and
> unsolved problems there. So I don't want to be pushed to fix bugs in the
> IDE docking manager now, moreover I did not write it.
I see no reason for postponing fixes which work and don't affect the
operation outside dragging operations.
> At the same time if you are able to create a working example which
> proves that LCL docking (LDockTree) has the same problems you describe
> in the bug report I am ready to fix them.
The IDE is a working example, where everybody can both observe the
misbehaviour and how it is fixed by the supplied patch.
I agree that more research is required, what in detail causes the bad
calls and property settings. *This* part can be delayed, or can be
omitted at all, when the known solution already prevents any fatal
More information about the Lazarus