[Lazarus] Docking and Layout managers

[Michael Van Canneyt]

On Mon, 9 Feb 2009, Mattias Gärtner wrote:

> Zitat von Hans-Peter Diettrich <DrDiettrich1 at aol.com>:
> 
> > Mattias Gärtner schrieb:
> >
> > > Maybe I misunderstood your proposal.
> > > What parts of TWinControl should be moved to TContainerControl?
> > > Do you want to move the ControlCount and Controls properties to
> > > TContainerControl?
> >
> > Yes, all the child control related stuff. I'd move that into the
> > LayoutManager, and redirect all related methods and properties to that
> > helper object. Then the LayoutManager is as exchangable as the DockManager.
> >
> > > What about TControl.Parent?
> >
> > It will be of type TContainerControl, of course. I admit that the tests
> > for TWinControl have to be revised accordingly, but there remains more
> > to do. E.g. it's nonsense when TWinControl redirects docking and other
> > messages to TControl, which then again delegates the job back to its own
> > TWinControl parent. All that docking and child control handling stuff
> > should be entirely removed from TControl, and also from TWinControl, and
> >   instead should be moved into the layout and docking helper objects.
> > I'm just about to find all that stuff, and to implement a direct
> > connection between e.g. TDragManager, TDockPerformer, and the DockManager.
> >
> > The legacy interface of all classes can survive that update, the revised
> > methods only will redirect the tasks immediately to the final worker
> > object. These are highly desireable changes, regardless of whether we
> > introduce a new layout layer class or not. We might use conditional
> > compilation, so that in case of trouble the old class tree remains
> > intact, for debugging and as a last resort in case of trouble with
> > legacy code.
> >
> > IMO we should cut some of the old trees, in order to see the wood for
> > trees again.
> 
> First of all: Yes, that would be better from object oriented point of view.
> 
> But:
> At least 90% of TWinControl is about its child controls. The rest is mostly key,
> mouse and focus handling. I guestimate, TContainerControl will have about
> 1-3kloc code, 500loc will stay in TWinControl and the remaining 4-6kloc will go
> to the new docking/layout classes.
> There is no question, that such a big change is Delphi incompatible. The
> question is how much:
> 
> - A lot of code (outside the LCL) relies on the fact, that AControl.Parent is a
> TWinControl and has a handle (exact: can have a handle).
> 
> The compiler will not find all places that needs to be fixed. For example:
> 
> procedure RecursiveCall(AWinControl: TWinControl);
> begin
>   for i:=0 to ControlCount-1 do
>     if Controls[i] is TWinControl then
>       RecursiveCall(TWinControl(Controls[i]));
> end;
> 
> This recursive call won't find all children anymore.
> 
> So all users have to check every place manually, where TWinControl is used and
> maybe replace it with TContainerControl.

I don't think this is a very good idea.

Michael.