Hi.
I have a problem regarding the order of files show in the "Project" management tab.
All the project files are dispatched in virtual folders.
The problem is that for some projects, the files are sorted alphabetically in each virtual folder (witch is what I want), but for some others, the order is strange.
I've attached a png image with a small screenshot of 2 projects with the differents behaviour.
And I can't find any way to make the files being sorted (perhaps I'm missing something).
I tried removing the corresponding project "layout" file, but nothing changed.
Is there a way to reorder the files (automatically or not) ?
Thanks in advance.
Regards
Xav'
Edit : I forgot to give precisions on my install : Windows 7 / C::B Nightly-Build 10050 (but I've already saw the problem with older versions)
Hi.
Sorry to "up" this topic, but I'd really like to know if there is an issue to this or not.
Regards
Xav'
I have the the same problem ( random file ordering in virtual folders ).
Please note that the files are correctly alphabetically sorted :
* in the OpenFilesList plugin
* in the .cbp file
Can you make a minimal test project which can be used to reproduce the problem?
Something wrong with the .layout file I presume
Quote from: earlgrey on July 15, 2015, 10:41:55 PM
Something wrong with the .layout file I presume
Unlikely, but if true have Code::Blocks closed and delete the .layout file.
Tim S.
Hi
Quote from: stahta01 on July 16, 2015, 01:04:47 AM
Quote from: earlgrey on July 15, 2015, 10:41:55 PM
Something wrong with the .layout file I presume
Unlikely, but if true have Code::Blocks closed and delete the .layout file.
Tim S.
It's one of the first things I've tested, but it doesn't do anything.
Quote from: Xaviou on January 14, 2015, 06:22:19 PM
......
I tried removing the corresponding project "layout" file, but nothing changed.
......
You'll find attached the result of 4 consecutives attemps to open this workspace : nothing else was done, just opening the workspace and closing it.
Regards
Xav'
I made a dummy project with the same files, mis-ordering happends when moving all files from the virtual folder they were put in when files were added to the project ( lets say virtual folder A ), into another virtual folder.
When moving the files again in the A virtual folder, filenames are correctly sorted again.
Is the filename's sorting done in a library that I may have recently upgrade ? Never had that problem before, and using the same version of C::B & wx for a while.
Quote from: earlgrey on July 16, 2015, 05:15:37 PM
I made a dummy project with the same files, mis-ordering happends when moving all files from the virtual folder they were put in when files were added to the project ( lets say virtual folder A ), into another virtual folder.
When moving the files again in the A virtual folder, filenames are correctly sorted again.
Is the filename's sorting done in a library that I may have recently upgrade ? Never had that problem before, and using the same version of C::B & wx since a while.
FYI: I have noticed changes in how projects are displayed NOT related to your issues that are fixed by closing and reopening the project.
I some times do a save-as over the same project name to be certain it was saved before closing.
Tim S.
So is there a problem or not?
Please post the exact steps to reproduce.
Hi.
The problem is still present.
It appears with some projects, and not with the others.
But I've not yet found where it comes from :
- for some projects, the files are alphabetically ordered in virtual folders
- for some others, they are randomly ordered (as you can see in the last screenshot I've posted).
I'll try to provide a small project that shows this problem (I can't yet with the project shown in the screenshot as it isn't open source and I'm not the owner).
Regards
Xav'
Hi.
I've cleaned the content of the project files (all sources files contains only its name).
I've attached an archive with the resulting workspace for witch the problem is still remaining (the goal is only to open it to see the problem).
I've also attached another screenshot of the project management tab with successives open/close of this project.
Regards
Xav'
Quote from: oBFusCATed on July 18, 2015, 01:26:53 PM
So is there a problem or not?
Please post the exact steps to reproduce.
Yes. Here are simple steps ( I did not save workspace, neither project during these steps ) :
01) Create this simple project : https://i.imgur.com/QP7VN5T.png (https://i.imgur.com/QP7VN5T.png)
( one workspace, one project, 9 little text files under a "src" folder, each two byte size ( 1 alphabetical char + newline ) )
02) Add a virtual folder "a" : https://i.imgur.com/kbphFvY.png (https://i.imgur.com/kbphFvY.png)
03) Move all files to "a" : https://i.imgur.com/zST91CT.png (https://i.imgur.com/zST91CT.png)
04) Add a new virtual folder "b" : https://i.imgur.com/lt7pXjN.png (https://i.imgur.com/lt7pXjN.png)
05) Move all files from "a" to "b" : https://i.imgur.com/fpSdtB7.png (https://i.imgur.com/fpSdtB7.png)
Files are now mis-sorted in b !
06) Delete virtual folder "a" : https://i.imgur.com/nlFxImx.png (https://i.imgur.com/nlFxImx.png)
All files automagically well-sort themsleves in "b" !
=> Seems like items sorting in the wxTreeCtrl is buggy.
Bug is present in recent svn version 10373 :
Code::Blocks svn build rev 10373 Jul 29 2015, 18:44:13 - wx2.8.12 (Linux, unicode) - 64 bit
OK, got it ( using compiled version described above )
When I load a sample project I made for this post's purpose, I get :
http://www.mediafire.com/view/s565sfhf03nql72/08.png (http://www.mediafire.com/view/s565sfhf03nql72/08.png)
Here are the steps :
I) Project gets loaded ; files are inserted in the cbProject.m_Files member :
ProjectFile* cbProject::AddFile(int targetIndex, const wxString& filename, bool compile, bool link, cb_unused unsigned short int weight)
{
...
m_Files.insert(pf);
...
}
with m_Files beeing a wxHashSet :
This is a simple, type-safe, and reasonably efficient hash set class, whose interface is a subset of the interface of STL containers.
Insert_Result wxHashSet::insert(const value_type &v)
, as declared in "projectfile.h".
WX_DECLARE_HASH_SET ( ProjectFile*, wxPointerHash, wxPointerEqual, FilesList );
Lets dump m_Files as projectfile objects are inserted inside it :
ProjectFile* cbProject::AddFile(int targetIndex, const wxString& filename, bool compile, bool link, cb_unused unsigned short int weight)
{ ...
m_Files.insert(pf);
for (FilesList::iterator it = m_Files.begin(); it != m_Files.end(); ++it)
{
ProjectFile* gpf = *it;
LOG("cbProject::AddFile():%s\n", gpf->relativeFilename.mb_str(wxConvUTF8).data());
}
...
}
which gives :
INF:[a1473a00]:cbProject::AddFile():../src/a.txt
INF:[a1473a00]:cbProject::AddFile():../src/a.txt
INF:[a1473a00]:cbProject::AddFile():../src/b.txt
INF:[a1473a00]:cbProject::AddFile():../src/c.txt
INF:[a1473a00]:cbProject::AddFile():../src/a.txt
INF:[a1473a00]:cbProject::AddFile():../src/b.txt
INF:[a1473a00]:cbProject::AddFile():../src/c.txt
INF:[a1473a00]:cbProject::AddFile():../src/d.txt
INF:[a1473a00]:cbProject::AddFile():../src/a.txt
INF:[a1473a00]:cbProject::AddFile():../src/b.txt
...
INF:[a1473a00]:cbProject::AddFile():../src/c.txt
INF:[a1473a00]:cbProject::AddFile():../src/d.txt
INF:[a1473a00]:cbProject::AddFile():../src/g.txt
INF:[a1473a00]:cbProject::AddFile():../src/i.txt
INF:[a1473a00]:cbProject::AddFile():../src/a.txt
INF:[a1473a00]:cbProject::AddFile():../src/f.txt
INF:[a1473a00]:cbProject::AddFile():../src/h.txt
INF:[a1473a00]:cbProject::AddFile():../src/b.txt
INF:[a1473a00]:cbProject::AddFile():../src/e.txt
II) Then ProjectManagerUI::BuildProjectTree() is called,
void ProjectManagerUI::BuildProjectTree(cbProject* project, cbTreeCtrl* tree, const wxTreeItemId& root, int ptvs, FilesGroupsAndMasks* fgam)
{
...
// iterate all project files and add them to the tree
...
// add file in the tree
pf->SetTreeItemId(ProjectAddTreeNode(project, tree, nodetext, parentNode, useFolders, folders_kind,
pf->compile, (int)pf->GetFileState(), ftd));
which iterates as I did for dumping m_Files
III) At each iteration, ProjectAddTreeNode()@projectmanagerui.cpp is called :
wxTreeItemId
ProjectAddTreeNode(cbProject* project, wxTreeCtrl* tree, const wxString& text, const wxTreeItemId& parent,
bool useFolders, FileTreeData::FileTreeDataKind folders_kind, bool compiles, int image,
FileTreeData* data)
{
...
int pos = path.Find(_T('/'));
if (pos == -1)
pos = path.Find(_T('\\'));
if (useFolders && pos >= 0)
{
....
}
else
{
ret = tree->AppendItem(parent, text, image, image, data); // (L1)
...
}
which always ends up, for simple filenames, ( that does not contain any path separator ) at the line (L1) by appending an item - so adding it at the end of "tree".
So no sorting is apparently performed anywhere.
I suppose it is the same bug when moving files across ( virtual or not ) folders.
Please consider, in projectmanagerui.cpp :
wxTreeItemId
ProjectAddTreeNode(cbProject* project, wxTreeCtrl* tree, const wxString& text, const wxTreeItemId& parent,
bool useFolders, FileTreeData::FileTreeDataKind folders_kind, bool compiles, int image,
FileTreeData* data)
{
...
int pos = path.Find(_T('/'));
if (pos == -1)
pos = path.Find(_T('\\'));
if (useFolders && pos >= 0)
{
....
}
else
{
ret = tree->AppendItem(parent, text, image, image, data); // (L1)
...
}
at line (L1), replacing AppendItem(...) by InsertItem(...) ( call to ProjectFindNodeToInsertAfter(...) needed )
That resolves the bug, but I cant figure out what it can breaks elsewhere.
Please post a real patch. 8)
Not for the moment, I am working on
- my externel lexer loader for scintilla ( which works but will never be accepted by Neil )
- my enhanced OpenFilesList plugin
http://www.mediafire.com/view/qawkuoi05ac8qvu/2015.08.20-cb%20LexerExt%20OFL.png# (http://www.mediafire.com/view/qawkuoi05ac8qvu/2015.08.20-cb%20LexerExt%20OFL.png#)
trunk@svn10640 - ProjectTreeSortChildrenRecursive()@ProjectManagerUI.cpp : remove the red part and it is ok
static void ProjectTreeSortChildrenRecursive(cbTreeCtrl* tree, const wxTreeItemId& parent)
{
wxTreeItemIdValue cookie = nullptr;
tree->SortChildren(parent);
wxTreeItemId current = tree->GetFirstChild(parent, cookie);
while (current && tree->ItemHasChildren(current))
{
ProjectTreeSortChildrenRecursive(tree, current);
current = tree->GetNextChild(parent, cookie);
}
}
It breaks the recursion traveling ; current may not have children, but may have brothers :
while (...) loop :
current ( = first child )
|
+------------------------------------+
| |
has children dont have children
| |
v v
- recursion on current's children - missing loop on current's brothers
- loop on current's brothers
You may put the optimization test on 'sterile' nodes inside the while (...) loop. Or code a recurse process differently.
I guess you're proposing a fix for the original issue, right?
Can you post a tested patch? ::)
Here it is, I did
diff -au projectmanagerui.cpp@10648 projectmanagerui.cpp@earlgrey > projectmanagerui.cpp.patch
so you patch with
patch projectmanagerui.cpp projectmanagerui.cpp.patch
I :
* added an optimization at method begin
* moved the misplaced original one.
-> bye bye, bug :)
Quote from: earlgrey on January 17, 2016, 07:18:10 AM
Here it is, I did
diff -au projectmanagerui.cpp@10648 projectmanagerui.cpp@earlgrey > projectmanagerui.cpp.patch
This won't work on Windows (easily). Can you please just use SVN to create a patch file as suggested?
In your SVN working copy, please run: this command:
svn diff > my.patch
BTW: Morten have you tried to install git bash? It contains most of the unix tools, so it might have a working version of the patch tool.
Quote from: oBFusCATed on January 17, 2016, 11:07:49 AM
BTW: Morten have you tried to install git bash? It contains most of the unix tools, so it might have a working version of the patch tool.
Sure and not only that, so I think I have plenty of versions of "
patch", but you don't really want me to go to the command line on
Windows, just to apply a patch, right? What frustrates me is that there is an easy way using SVN to create and apply patches, but we get them in so many different formats and for each format I need a special tool. I remember that previously even "
patch" was not "
patch" but you needed a special version...
Oh it could be that
simple... ;D
Here it is
$ cd codeblocks-code
$ svn diff > projectmanagerui.cpp@10668.svn-diff.patch
I see patch has not been yet applied ; If you are afraid of modifying core C::B's UI with not-well-tested patch, you shouldn't : bug was only a small inattention error.
In svn after some cleanup and simplification. Thanks.