User forums > Help
C::B corrupts project layout
Jenna:
--- Quote from: oBFusCATed on October 30, 2015, 08:34:39 am ---Probably this is related to the changes done by Jens to support preserving the splits in the layout.
--- End quote ---
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:
--- Quote from: oBFusCATed on October 30, 2015, 08:34:39 am ---Probably this is related to the changes done by Jens to support preserving the splits in the layout.
--- End quote ---
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:
--- Quote from: l_inc on November 02, 2015, 02:46:16 pm ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version