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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
