Mattias Gaertner schrieb:
This bypasses OnShowForm, when a DockMaster is installed. Is this
intended? What's the purpose of OnShowForm?
OnShowForm existed for compatibility, but it is now obsolete. I
removed it.
Fine :-)
IMO the DockMaster should not be involved in ShowForm, this method is
called too often in the IDE code. The only situations, where the
DockMaster really is involved, are:
- MakeWindowDockable
- MakeWindowDockSite
- Save/RestoreLayout[1]
Showing a form can restore the old position or putting it at a
default position. Your dockmaster don't need to implement the restore.
Huh?
The docked layout is entirely implemented in the DockMaster, the IDE
(layout and creators) have no idea of that layout.
ShowForm should handle (already) docked forms by means of
TWinControl.ShowControl, which e.g. already handles forms in notebook
pages (switches to the according page). I'd add the following features
to ShowControl:
- make it public
- add an BringToFront parameter (default True?)
- also make parents visible
That would be Delphi incompatible. We have to create a new method for
this.
What reasonable incompatibility do you see?
ShowControl already is recursive, i.e. parents become visible.
An added parameter with a default value doesn't break anything, IMO.
- when called with AControl=nil, show itself
The last item means: when the form has no parent,
form.Parent.ShowControl(form) is not applicable. This special situation
can be handled in ShowControl, when called as form.ShowControl(nil), so
that the caller doesn't have to care. I can supply an according patch,
if you like.
Such a function is indeed useful. What could be a good name?
Please note that a new name will cause trouble, since ShowControl is
already overridden in certain control classes. A new method would
require the same overrides, and *that* is what would break compatibility.
Alternatively a BringToFront parameter could be added to Show,
default=True (stupid Delphi compatible).
Then TIDEWindowCreatorList.ShowForm can invoke AForm.ShowControl(nil,
BringToFront) instead of figuring out what should happen.
Showing can require docking. So ShowForm must use the dockmaster.
Please explain.
The (Delphi compatible) persistent docking saves/restores the contents
of docksites. Either forms already reside in a docksite, and only must
be made visible on demand, or they have to appear according to the IDE
Window settings when opened e.g. from the View menu.
The current DockSibling and DockAlign docking in the Creators bypasses
an DockMaster, with many consequential problems :-(
[1] As long as dockable forms are not supported by all platforms,
Basically it works. I use the docked IDE under gtk2, qt and carbon.
Does this mean that the wrapper hack is not required any more?
I used it only a few times under Windows.
Using which DockMaster/Manager?
WRT Delphi compatibility: Delphi compatible docking actually is broken,
in detail on Windows. If you think that AnchorDocking should be used
instead, I can stop any work on other docking models.
dockable forms have to be wrapped into a floating form, which offers
means to start docking the contained control. Since such floating sites
are handled by the DockMaster, all dockable forms are part of the
DockMaster layout, regardless of really docked or floating. The
remaining non-modal IDE forms are all docksites, which also are handled
by the DockMatster. This means that a DockMaster can restore the
complete IDE layout, when e.g. called from
IDEWindowCreators.RestoreSimpleLayout.
What about the floating forms that are neither docksites nor dockable?
These don't need any special (DockMaster...) handling :-)
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
