C::B corrupts project layout

[l_inc]

Good day. I have the following problem. If there are many files open in a project and with some planets incorrectly aligned C::B corrupts the layout file while just opening and closing the project. This includes for instance modification of some values position and topLine for the cursor. I attached a sample project, where opening and closing the project in C::B four times leads to splitting the view, which is then impossible to get rid of.
I'm getting this with CodeBlocks 13.12.svn.10538 on Fedora 22.

[Pecan]

svn build  rev 10538 (2015-10-18 12:10:34)   gcc 4.9.2 Windows/unicode - 32 bit

I too have experienced this problem: the screen splits when loading an additional project into the workspace.
Deleting the "<EditorTabsLayout layout=" entry in the layout file solved the problem.

[l_inc]

Pecan

the screen splits when loading an additional project into the workspace

The problem I reported is not related to loading additional projects. It's just enough to start and close the same project multiple times and the layout will gradually get corrupted eventually leading to the split view without any other projects involved.

Deleting the "<EditorTabsLayout layout=" entry in the layout file solved the problem.

It solves the problem of splitting for the next few loads of the project, and then the split will reappear. And it does not solve the problem of corrupting the other (even if those are minor) parameters of the layout.

[killerbot]

Today, I got this twice, never had it before (nearly latest trunk build)

[MortenMacFly]

Well that is interesting: Indeed, also on Windows if you open the provided project 3 times it starts splitting the editors... everytime after that another split gets introduced...

Well that is weird...

Lets see what the latest changes to the layout mechanism were...

[MortenMacFly]

One update: It seems related to the fact that the project file includes references to source files that are not present. Could you (guys) please verify if this also happens in case all files are really present? (You can use the "find broken files" plugin to clean-up the project).

[oBFusCATed]

Probably this is related to the changes done by Jens to support preserving the splits in the layout.

[Pecan]

No broken files were found by  "find broken files" on either of the two projects in the workspace.

[scarphin]

My implementation below overcomes (not fixes) this problem when enabled. It might help till the problem is fixed.
http://sourceforge.net/p/codeblocks/tickets/182/

[l_inc]

MortenMacFly

One update: It seems related to the fact that the project file includes references to source files that are not present.

Yes, that seems correct. No layout attributes get modified when there are no missing project files.

[Jenna]

Probably this is related to the changes done by Jens to support preserving the splits in the layout.

If the EditorTabsLayout-part is broken, this might be.
But this should not not chage cursor-position or top-line.
I try to investigate, but I'm very busy at the moment.

I only get it, if  some source files are not present.
I mean the "autromatically" split (and break layout) when closing and reopening the project.

The fact that the tabs of two (or more) projects might get incorrectly merged or (at least in an unecpected way) is another thing.

[Jenna]

Probably this is related to the changes done by Jens to support preserving the splits in the layout.

The issue with the example project of the OP should be fixed in trunk.
It was indeed, because of missing source-files,  with fileOpen-attribute-set in the layout file.
After some closing and opening, it ended with several fioles with the same tab-position.
And this seems to lead to a corruption in cbauibook::LoadPerspective().

I also changed the SavePerspective()-code in a way, that a project layout-file only saves the tab-layout of files belonging to the project, and that the tab-layout of files not belonging to any project is no longer saved.
Workspace-layout files should save the tab-layout of all files belonging to any project.

[l_inc]

jens
Thank you. The layout attributes are not continuously changed anymore. But I'd like to note that these still are modified as long as EditorTabsLayout contains those missing files. It's currently not usability critical, because the missing files are thrown out of EditorTabsLayout once the project is opened, and the layout attributes (such as tabpos, position and topLine) get then stable values, but the new values are read from some unexpected memory locations. So the bug is worked around, but still seems to persist and could get in the way later, e.g. as a crash resulting from a read from unallocated memory.

[Jenna]

jens
Thank you. The layout attributes are not continuously changed anymore. But I'd like to note that these still are modified as long as EditorTabsLayout contains those missing files. It's currently not usability critical, because the missing files are thrown out of EditorTabsLayout once the project is opened, and the layout attributes (such as tabpos, position and topLine) get then stable values, but the new values are read from some unexpected memory locations. So the bug is worked around, but still seems to persist and could get in the way later, e.g. as a crash resulting from a read from unallocated memory.

Can you please be more specific and write where values from unallocated memory are read ?

[l_inc]

jens
I did not debug it, and reading from unallocated memory was my speculation about such possibility. The point is that the layout attributes a still changed, if the layout contains missing files for whatever reason (might be a common situation btw., e.g. when switching between multiple git branches). I have no idea where the changed values actually come from. Hence the speculation. But the bug is worked around, not fixed.