Currently dragging is broken in the LCL, see Mantis #18525. Currently any attempt to undock a docked window makes at least a Windows application hang, in an unusable state, until a *different* application is activated by the user.

I see no reason why the submitted patch should not be applied, in order to make the DragManager more robust. The patch only affects dragging operations, has no effect when nothing is being dragged.

The arguments, why the patch should *not* be applied, deserve an substancial proof. Can anybody provide an example, where the fixed DragManager code would cause any *real* problems?

DoDi

Looks like the reasons were mentioned to you in the issue comments. You are trying to remove the code which is there for a reason. The reason was also mentioned to you. This is not the way to go - you are just trying to hide the problem instead of fixing it.

The arguments, why the patch should *not* be applied, deserve an substancial proof. Can anybody provide an example, where the fixed DragManager code would cause any *real* problems?

Best regards,
Paul Ishenin

Also about broken dragging.

I create a small application: Form1 with Panel with DockSite = True, Form2 with DragKind = dkDock, DragMode = dmAutomatic. I included LDockTree into the uses section.

The application perfecly docks and undocks the second form using mouse.

So I conclude that Docking is broken not in LCL but in non-LCL drag managers (e.g. those from examples directory).

Best regards,
Paul Ishenin

That's why I ask for more opinions.

You are trying to remove the code which is there for a reason. The reason was also mentioned to you.

The reasons are wild guesses, that's why I ask for an proof.

This is not the way to go - you are just trying to hide the problem instead of fixing it.

The problem is a the vulnerability of the DragManager, against bad coding practice. The patch makes the DragManager less sensitive to such errors, which (currently) can be made by everybody in his own code.

The current situation, and your arguments, read to the user like:

"We know that there exist bugs, and we know how to eliminate fatal consequences, but we prefer to leave our code in unusable state."

DoDi

It also works perfectly with the EasyDockManager.

So I conclude that Docking is broken not in LCL but in non-LCL drag managers (e.g. those from examples directory).

Your conclusions are wrong :-(

1) The choice of the DockManager does *not* affect the dragging behaviour of an application.

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.

DoDi

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.

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.

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.

Best regards,
Paul Ishenin

Hans-Peter Diettrich wrote

The current situation, and your arguments, read to the user like: "We know that there exist bugs, and we know how to eliminate fatal consequences, but we prefer to leave our code in unusable state."

This is how you see it. Read it so:

"We know that there exists bugs in the code outside LCL. We prefere the bugs fixed in that code instead of adapting LCL for the bad written code".

Best regards,
Paul Ishenin

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.

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 consequences.

DoDi

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.

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.

Obviously [1] is the simpler and more robust solution, because the DragManager is always involved. Moving the "dragging" check somewhere else, e.g. into the CaptureControl procedure, may result in more trouble, and has to be checked for every single control.

DoDi

The code which manually dock something in IDE should check the DragKing. Nobody except the developer should change this property, especially not the DragManager.

You need to find the control which changes the capture diring the drag and fix this control code.

Best regards,
Paul Ishenin

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.

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

Hans-Peter Diettrich wrote

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?

It is a normal situation when something is docked and have DragKind dkDock even I have no chance do undock it by mouse. If it works so it means that developer make it work so. It is useful in some situations and moreover I use this in my work projects when I want for example to integrate some form which may be a dialog in some cases into another form panel.

So when form is manually docked with DragKind dkDock is not a bug in LCL and LCL should not change this property.

If you oversve that some docked form should be undocked via mouse in IDE please change this in IDE.

> 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?

Why should I do this if IDE docking has not 1.0 target?

That was your patch. The patch had target 0.99 and I reviewed it. The patch is wrong. If you want to fix IDE docking problems please submit another patch which does not break LCL behavior.

Best regards,
Paul Ishenin

At least the IDE developer had a different intention.

But it's required to make the IDE dockable.

If you oversve that some docked form should be undocked via mouse in IDE please change this in IDE.

Not me :-(

Because it does not only affect the IDE, but dragging in general. Consequently 1.0 will not properly support dragging, in all applications.

That was your patch. The patch had target 0.99 and I reviewed it. The patch is wrong. If you want to fix IDE docking problems please submit another patch which does not break LCL behavior.

I'm tired of supplying patches which then are rejected, and searching bugs in deliberately broken code. Docking worked fine in earlier Lazarus versions.

DoDi