Currently I observe the following flaws (Win7):

1) An editor page in a secondary editor window *only* can be cloned into a new window. Why does the handling of secondary editor windows differ from the handling of the primary window???

2) Code completion still gets stuck all the time. The list is either blanked, or contains only "Bad..." entries.

3) Possibly related to secondary editor windows: a code template invocation (^J) can end up in a different window (previously active?). In most cases it helps to switch to an different tab/file in the originating window, and back again.

4) In IdeWindowIntf TIDEWindowCreator.GetDefaultBounds(), relative window extents are computed in a wrong way. In both horizontal and vertical direction the lines

     if aRight<0 then
       aRight:=ScreenR.Right-aRight // relative to right of screen

should be corrected into

       aRight:=ScreenR.Right + aRight // relative to right of screen

because aRight/aBottom is already negative!

DoDi

It shouldn't be different. Please report as a bug

You should still be able to drag/drop it back to the original window, holding CTRL for copy/clone

Would be good if reproducible.

Is that an IDE without docking, with docking (which)? Or does it happen independent of docking

Actually, I just checked on windows vista, and it works (2nd window allows cloning back to 1st window). I tested before, but tricked myself.

Please not when you test, that there is another restriction. Each unique file can only have one tab per window.

So if you cloned "unit1" from window-1 to window-2, then it is open in both windows. This means you can not clone (not move) it to window-1 as it is already open there.

Martin

Okay.

Ah, it looks as if a secondary editor window wrongly *thinks* that it is the only editor window, and constructs the popup menu accordingly. The menu of the primary editor correctly reflects other editors.

You should still be able to drag/drop it back to the original window, holding CTRL for copy/clone

No target responds to dragging, regardless of CTRL :-(

BTW, CTRL is the wrong modifier, it's intended to *ignore* all possible targets.

But the DragManager is broken since a long time, and nobody cares about according bug reports :-(

> 2) Code completion still gets stuck all the time. The list is either > blanked, or contains only "Bad..." entries.

This one possibly has been fixed, cannot reproduce such errors after SVN update?

Cannot reproduce after SVN update :-)

Is that an IDE without docking, with docking (which)? Or does it happen independent of docking

Seems unrelated to docking.

DoDi

Is there an official definition for that somewhere?

Because even microsoft uses it that way. Using the windows (file) explorer:
- If I drag/drop a file (with no modifier key): It is movedor copied (depends on same/other disk
- With CTRL: always copy
- with shift: always move

In none of those cases any modifier key has anything todo with "ignoring possible targets"

I haven't tested that.

But the bug is *probably* unrelated to the above:

The rule for "Each file only once per window" applies to "linked/shared" editors. (Edit the file in one place, updates all other places / Internally the IDE has that file open ONCE)

Your case *sounds* as if (I have not tested it) the file is opened a 2nd time, and the IDE treats it as 2 different files.
Out of interest: did you compare the full filenames (path + name)?

The display disabled menu entry, instead of display none makes sense.

Jumping to the same source, in an other window, is an interesting feature, but should not be unde "move/clone" menu, (imho it would lead to confusion there).
There could be a sub menu "find in other window"; though that leads to more menu entries in the main popup, and the popup is already very big.

Related issue: can the entries in the Window menu be sorted alphabetically, so that it will be easier to find and activate a page by name?

probably, but I don't know anyone working on it.... Discussions on this and similar had been plenty in the past. An extension package could also solve this, displaying files in many interesting ways in a file navigation window)... but no one has yet written it.

I think the maximum of open files (not tabs, but unique files) I have ended up with so far, would be around 40.
The maximum number of source windows I ever used would be around 9

BTW, you are away of the "page locking" feature ?
http://lazarus-dev.blogspot.com/2010/04/page-locking-or-multiply-editor-windows.html

Assign it to a key-shortcut.

Then lock the current editor, and to a declaration jump. With the default settings, this should go to the file in the last-focused-editor-for-that-file (can be changed to Editor-for-that-file-in-the-most-recent-focused-window) That is, if the jump target is not already visible in the window...

An other option would be, 2 have several sections in the sub menu.

"Clone to Window" (Submenu)
"Clone to new window"
-----
"Clone to window 1"
"Clone to window 3"
-----
"Goto to window 2 (existing clone)"

Actually, I just checked on windows vista, and it works (2nd window allows cloning back to 1st window). I tested before, but tricked myself.

Oops, *this* seems to be the reason!

Please not when you test, that there is another restriction. Each unique file can only have one tab per window.

That's okay, but the IDE breaks even this rule :-(

When a project is loaded, and problems in the resources (.lfm) are found, this file is opened *twice* in the same window. When this happens, it's highly recommended to create a new project and cancel updates of the old project - everything else will lead to strange errors, up to making the IDE unresponsive :-(

So if you cloned "unit1" from window-1 to window-2, then it is open in both windows. This means you can not clone (not move) it to window-1 as it is already open there.

That's okay so far but, as you see, it can lead to confusion. I've just added another (lengthy) note to issue 19666, that explains what I consider *desired* behaviour instead:

The Clone menu should allow to simply *activate* an already existing *or* newly created clone. Currently it can be very time consuming to scroll through the tabs of the target window, shifting one by one, until an already existing clone is found there.
I already suggested an pagewise scroll through the tabs, instead of shifting one by one, but this idea was rejected a long time ago...

Related issue: can the entries in the Window menu be sorted alphabetically, so that it will be easier to find and activate a page by name?

Of course it's a matter of personal preferences, how many files and clones should be open at the same time. At least I can end up in *very* many open files, when a change in source code results in compiler errors and consequential updates of many dependent files. It can be helpful to keep all these files open, in case the preceding updates should be modified again...

DoDi

Your case *sounds* as if (I have not tested it) the file is opened a 2nd time, and the IDE treats it as 2 different files.

Right, I noticed that only after your hint. My bad :-(

IMO a modification to the menu titles would be sufficient. Instead of definite "Clone to..." a "Show clone in..." could serve both purposes: Create a new clone only if none already exists in the target window.

I think the maximum of open files (not tabs, but unique files) I have ended up with so far, would be around 40. The maximum number of source windows I ever used would be around 9

Wow, now I'm happy to know that I'm not the only one, who uses multiple editors and many open files at the same time :-)

DoDi

BTW, you are away of the "page locking" feature ? http://lazarus-dev.blogspot.com/2010/04/page-locking-or-multiply-editor-windows.html

Wow, really great. It will become one of my favorite Lazarus features, now that I know about it :-)

DoDi

> BTW, CTRL is the wrong modifier, it's intended to *ignore* all > possible targets. Is there an official definition for that somewhere?

Is "Delphi" official enough? ;-)

But you may be right, above applies to drag-dock, not to drag-drop. In notebook-docking the notebook tabs are designed for drag-dock, not for drag-drop. Otherwise it were impossible to undock a page into floating state. The different handling in the Lazarus editor is somewhat confusing...

DoDi

Hans-Peter Diettrich wrote

Martin schrieb: > The display disabled menu entry, instead of display none makes sense.

Hm, on further thought. displaying source-editors to which you can not move/clone as "disabled" menu entry, brings up a few questions.

- Should the current window also be shown? (Since it is not "other" I would not show it.

It would remove a current optimization:

If a file already has an editor in every window, then they would have to be all listed as disabled.
BUT currently in this case, the entire sub menu is hidded, and the pop-up contains the only entry that makes sense "move/clone to NEW window"

Also showing disabled menu entries, is fine, if there are few disabled. But having 8 windows open, with 7 disabled, and 1 enabled.....

Having to think about

Martin

The menu entries also could be marked in a way, that allows to determine whether a clone already exists there (not need to create a new one), or not (will result in creation of a new clone). Then every menu entry can be kept enabled, with only slightly different semantics.

DoDi