Some flicker and other nasty things can be caused by excessive or inappropriate coordinate re-calculations while docking. This is partially caused by the flawed Delphi implementation, and is made even worse in further LCL hacks. Since the TDockManager interface has been improved already, much code can be removed from the LCL.
First we should agree that managed and unmanaged docksites require different handling of docking coordinates and other details. When a DockManager is installed in the target site, it will manage the DockRect (visual feedback) and finally will adjust the placement of the dropped control, including dock headers etc., eventually overriding user changes in event handlers. Without an DockManager, some calculations should be performed and reflected in the DockRect, and no final adjustment should be performed - this would be fooling the user. Also the calculation of BoundsForNewParent is questionable, at least for managed sites. Premature changes of the BoundsRect are a bad idea at all.
I'll outline the required changes to the TControl and TWinControl classes in futher comments to this entry, based on Lazarus revision 24970.
Subscribe to:
Post Comments (Atom)
TControl.CalculateDockSizes saves the docked and undocked extent of the control. This is a bad idea by itself, since that could be done separately in the dedicated methods, but it can be left as is.
ReplyDeleteNonetheless the docked coordinates should be stored both, independent from DockOrientation - their usage is up the DockManager, which can be different for every site!
TControl.CreateFloatingDockSite should establish the ClientWidth/Height of the site, based on the given DockRect. I'm not sure whether the current algorithm does this in the correct way. Eventually the DockManager should be asked, so that eventual dockheaders etc. can be taken into account. A final adjustment can be made, based upon the requested and established extent of the docked control, after the control really has been docked. All this will be done somewhere else, e.g. in ManualFloat or DoFloatMsg (should share all shareable code).
ReplyDeleteAnother problem is the Owner of the floating site. For persistent layouts a dedicated owner of all floating sites may be required, as implemented in TDockMaster.
TControl.DoDock should do nothing special. For a managed docksite its DockManager will place the control. In an unmanaged docksite the DockRect (visual feedback!) should be used without any modification. Eventual modifications must be moved into e.g. PositionDockRect, before the resulting DockRect is shown. Anchors and Align apply to the old Parent, and are not applicable to a managed docksite.
ReplyDeleteAnchoring dockable controls IMO is a bad idea at all, and should be handled in user supplied handlers.