Zitat von Hans-Peter Diettrich <[email protected]>:
> 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.
Mattias
_______________________________________________
Lazarus mailing list
[email protected]
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
