Mattias Gaertner schrieb:
The unit ldockctrl is only about anchordocking. You don't need to use or alter it for your docking manager.
LDockCtrl describes the interface that is nailed into the IDE units and methods. It would be very hard to remove all that stuff, and after all it has to replaced by something similar. That's why I want to retain that interface, and only change it to use a different management internally.
Have you solved the layout restore in your docking manager?
I can't, as long as I don't know how the IDE windows are created and managed (owners...). There seems to exist a dedicated OwningComponent in the IDE, that holds references to some (most? all?) IDE windows. The IDE also has to iterate over all windows when the configuration is stored, it's not yet clear to me how this works (TIDEWindowLayoutList?).
In a simplified model every persistent IDE window should "register" itself after creation. This could be done in an extended version of the OwningComponent, or in IDEWindowLayoutList.Apply and OnApply, which would make the added forms dockable. Afterwards the forms can be docked by the user, all related information is available in their HostDockSite. All other stuff, introduced with anchor docking (ControlDocker...), can be removed from the forms and other classes. The host sites can be managed independently, but their coordinates and layout should be stored along with the other forms' layout description. When the layout is restored after the next start, the stored information can be used in IDEWindowLayoutList.Apply, to create the dock sites and dock the forms.
DoDi -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
