Hi, I don't know what I did to mess up my project, but now, every file I open to edit, it's opened in a 2nd source code editor window, instead of the main one.

This behavior only happens in one project. How can I force the IDE to open pascal files in the first source code window?.

Thanks in advance,

Well, I figured out how to move the files from the 2nd editor window to the main one.

Now, the 2nd editor window is empty...but every time I open my project, that window is opened also. How can I eliminate that window from my project?.

If you close the window (normal "X" close button), and save the project, then it should be kept closed.

However, if you use the docking manager, then it may not be so easy. Last time I checked (quite a while ago though) the dockingmanager was buggy, and didn't allow closing the window.

A none docking IDE should only open the window, if there is at least one unit to be loaded into it => so moving them all to the one primary window, and restart should also solve it.

I'm using the docking manager. So it might be a bug.

This seems to work, but currently I have the following issues with the non-docking IDE:

IDE
---
02 MainBar extent should be configurable (at least not 100% wide). 03 Form positions should accept negative coordinates. 04 Forms should be moved (and clipped) into monitor bounds. 05 Save layout with *current* window positions.
06 Properly adjust with negative width/height values.

02 is a private wish for wide screens, where I prefer a 50% wide MainBar, and a full-height editor window to its right.

03-05 are tightly coupled. In general the forms should allow for all valid coordinates, i.e. also negative ones (my secondary monitor has negative Y coordinates). On exit the IDE should save the current window positions, in a way that these are restored on the next start. There seems to exist a problem with the default window placement property, that is not always set to "custom".

06 is a trivial one, the form size currently is extended instead of shrinked (subtracting negative value).

I've almost fixed above issues, but currently I only can provide Git commits or patches. My SVN copy has too many unrelated updates in it, so that I cannot provide specific patches.

However, if you use the docking manager, then it may not be so easy. Last time I checked (quite a while ago though) the dockingmanager was buggy, and didn't allow closing the window.

Anchor docking seems to work, when I tested it some time ago, but "normal" docking now is broken in several ways. Some problems seem to be added by the IDE, where e.g. docked forms cannot be undocked.

Dockable IDE
------------
01 FormCreators only should be used when a form is created, not later. Forms should be made visible/foreground by standard procedures. 02 Forms should be really dockable (dkDock, see also: docking). 03 Options:Windows should always show window positions. 04 MainBar should have all contents in a panel or frame, so that other windows can be docked into it (elastic sites).

01 may be a general problem, when the IDE (creators...) think that form coordinates are invalid and try to "fix" them - even if the form was moved by the user [see negative coordinates above]. Also a general MakeVisible method should be implemented, that works across tabbed and scrolling controls - this can not be done by a docking manager. ShowControl seems to be a good starting point for this feature.

02 may be related to the broken DragManager, or missing MakeDockable calls. I see no reason for MakeDockable at all, since a DockMaster knows what to do on ShowForm.

03 is required for debugging and repair of clobbered window settings.

For completeness I add the docking issues:

Docking
-------
01 DragObjects should replace DragPerformers.
02 DragManager should pass all messages to DockManager or DragObject, not to controls.
03 TDockWindow is unusable (on Windows).
04 Docked windows should be dkDock, to allow for undocking. 05 CaptureControl changes should not stop drag/dock.

01/02 are (optional) improvements, that allow for better integration of docking managers. The Delphi model allows to customize docking in special DockObjects, supplied by the user or by an DockManager/DockMaster. The Lazarus DragPerformers do not allow for such customization. Furthermore the Delphi model *and* the Lazarus implementation is too much fixed on TDockTree. E.g. a GetDockEdge method and DockAlign parameter is useless with other docking managers, and the Lazarus implementation contains many hacks, that may be required for AnchorDocking. Leaving all that stuff to concrete DockManager, DockMaster or DockObjects would increase the flexibility, with possibly multiple coexisting DockManagers; it also would assure that inappropriate handling of docking messages in TControl does not affect the operation of concrete docking objects.

03-05 are obvious, any attempt to start a docking operation hangs applications (including the IDE).

A none docking IDE should only open the window, if there is at least one unit to be loaded into it => so moving them all to the one primary window, and restart should also solve it.

One problem seems to be the storage of even empty editor windows in the options. The window persistence seems to have be improved, but still suffers from above and possibly more problems.

DoDi

I'm using the docking manager. So it might be a bug.

Which docking, on which platform?

The EasyTree dockmanager currently is broken by bugs in the LCL (DragManager, TDockWindow) and in the IDE. AnchorDocking may work, and the related hacks may be the reason for the problems of other docking managers.

DoDi