Closed klaus101 closed 1 year ago
@klaus101 Thanks for letting me know. I will fix it so that it sorts in the same order as the standard Windows Explorer. In the tree view, elements preceded by an underscore will be sorted from the top, as in the list view.
@funap
Big thanks for you understanding and effort!
Fixed in the release of 1.8.2.19
Describe the bug At least in german localization, in the most used file explorers items with leading underscores are sorted at the beginning, not at the end of the list. This did lead to some habits, where it is convenient to structure and organize data accordingly. Example. __savedVersions _tempStuff Work1 Work2
Folllowing this habits, it is irritating to not find the data where they are expected to be, but at the end of a list. It's worthy to notice that folders and files within the listview do meet this expectation. Whereas not withiin the treeview. Here they are sorted at the end of the list.
To Reproduce Steps to reproduce the behavior:
Expected behavior In the treeview elements with preceding underscores are sorted in the beginning, like they do withini the listview
Screenshots If applicable, add screenshots to help explain your problem.
Debug Info Notepad++ v8.5 (64-bit) Build time : Mar 6 2023 - 02:18:13 Path : D:\Test\NPP\notepad++.exe Command Line : Admin mode : OFF Local Conf mode : ON Cloud Config : OFF OS Name : Windows 10 Home (64-bit) OS Version : 22H2 OS Build : 19045.2673 Current ANSI codepage : 1252 Plugins : Explorer (1.8.2.18) mimeTools (2.9) NppConverter (4.5) NppExport (0.4) NPPJSONViewer (2.0.4)```
Additional context The funap explorer plugin is the x64 version. NPP is 8.5 x64 the portable version
If the issue should be accepted, it might be relevant to know:
In a quite different context / different language i had the same situation, a component that ordered unexpectedly. But it did allow a custom sort for the sort callback. Here i noticed, that the issue could be resolved by a routine called "AnsiCompareText" (the name might be meaningful). I had to constate though that AnsiCompareText behaved noticeably slower than the default sort. So, i ended up to use a kind of compromise: 'pseudo-code": if item-to-compare contains "_" then Compare := AnsiCompareText(S1, S2) else Compare := DefaultCompareText(S1, S2)