Files order in virtual folders

User forums > Using Code::Blocks

<< < (3/6) > >>

Xaviou:
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'

Xaviou:
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'

earlgrey:

--- 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.

--- End quote ---

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
( 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

03) Move all files to "a" : https://i.imgur.com/zST91CT.png

04) Add a new virtual folder "b" : https://i.imgur.com/lt7pXjN.png

05) Move all files from "a" to "b" : https://i.imgur.com/fpSdtB7.png
Files are now mis-sorted in b !

06) Delete virtual folder "a" : https://i.imgur.com/nlFxImx.png
All files automagically well-sort themsleves in "b" !

=> Seems like items sorting in the wxTreeCtrl is buggy.

earlgrey:
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

Here are the steps :

I) Project gets loaded ; files are inserted in the cbProject.m_Files member :

--- Code: ---ProjectFile* cbProject::AddFile(int targetIndex, const wxString& filename, bool compile, bool link, cb_unused unsigned short int weight)
{
...
m_Files.insert(pf);
...
}

--- End code ---

with m_Files beeing a wxHashSet :

--- Code: ---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)

--- End code ---

, as declared in "projectfile.h".

--- Code: ---WX_DECLARE_HASH_SET ( ProjectFile*, wxPointerHash, wxPointerEqual, FilesList );

--- End code ---

Lets dump m_Files as projectfile objects are inserted inside it :

--- Code: ---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());
}
...
}

--- End code ---
which gives :

--- Code: ---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

--- End code ---

II) Then ProjectManagerUI::BuildProjectTree() is called,

--- Code: ---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));

--- End code ---
which iterates as I did for dumping m_Files

III) At each iteration, ProjectAddTreeNode()@projectmanagerui.cpp is called :

--- Code: ---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)
...
}

--- End code ---
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.

earlgrey:
Please consider, in projectmanagerui.cpp :

--- Code: ---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)
...
}

--- End code ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version