Name Sort Order faulty (file names with numbers and letters)

A similar bug had been reported recently but apparently the fix didn't truly fix this.

https://oss.azurewebsites.net/forum/tracke...cker_bugid=697

FlashFXP 4.2.2.1762 (on a current Windows 7 x64 with directory listing fixed/back to the old Win2k style) lists this as...



...while the windows explorer correctly sorts it as...

It looks like we bypassed the check for NoStrCmpLogical in the registry, so regardless of your Windows setting FlashFXP will always use the numerical sort.

I can add this into the next build.

Please test the following development build, FlashFXP now follows the settings defined in Windows based on the value of NoStrCmpLogical

https://oss.azurewebsites.net/testr/ffxp-dev-build.zip

Unzip the flashfxp.exe into your FlashFXP program folder.

It's probably not clear what I am after, even with the registry entry being "off" the sorting is incorrect. Look at the screenshot in general.

It should be...

01A123456AC*
01A123456AD*
01A123456CC*
01A123456DC*

...no matter if it's a logical sort or not at that point. So the 1A0123456 not being sorted properly may be a side effect and not necessarily part of the problem. The dev build you attached did not solve the issue.

I copied each file name exactly as shown in the screenshots and tested the sort ordering used in Windows explorer and in FlashFXP and the results are 100% identical using English, however perhaps the same is not true for other languages.

What is your windows locale?

I believe the sort order used in Windows might be manipulated by the windows locale, where as the sort method used by FlashFXP isn't applying the exact same logic.

Standard German version but AFAIK there is no difference it sorting between DE and EN, I'll see if I can reproduce this on a different machine without modifications to the windows sort algorithm. Thanks so far for the assistance, appreciated.

Just for cross-testing, do you know which build# the bug with ID 697 was fixed and got an earlier build for me to double check? I am reasonably confident that the problem was introduced with one of the recent updates...

Please re-download the dev build and see if these changes make a difference

https://oss.azurewebsites.net/testr/ffxp-dev-build.zip

In many builds the sort logic was flawed, sadly this has been drawn out for so long that I'm not sure if it would be worth testing older builds since those builds were flawed in one way or another.

I believe v4.0 used the StrCmpLogicalW() api, where as newer builds use a in-house method that is 10x faster.

Looks much better now, except the 1A... vs. 01A... order is still not the same as Windows does it. Are you checking that rtegistry entry for HKLM and HKCU or just one of them?

// Update

After double checking with the original files where I found this issue...



...it appears there is still a glitch in the procedure. See for yourself (1P* and 1Z*)...

FWIW, at least temporarily a solution might be to offer the "StrCmpLogicalW() API" as a possibility in Preferences > Interface > File Browser. I'd be OK with a more time consuming but working sort.

Does the previous file name list that you gave as an example now sort correctly?

In your last screenshot would it be possible to include the file names as text? Its very difficult to test using the exact same file names when I have to manually type each one out.

In all tests our in-house routine provides identical results to the API, but it looks like maybe you uncovered some new situations that we may need to evaluate and test.

The last dev build checks both registry locations current user and if not found then local machine.

It looks like the result from StrCmpLogicalW isn't 100% clear and the result is somewhat unexpected from my point of view.

The documentation describes the function as "Compares two Unicode strings. Digits in the strings are considered as numerical content rather than text. This test is not case-sensitive."

However in some situations the result was not as expected and MS adds some fuzzy logic to the evaluation.

The following items are sorted based on the logic from StrCmpLogicalW()

000
000_A
000_Z
00
0
1
11
111
111_A
111_Z

Our in-house method did not take into consideration the unusual ordering of 0's and this is why our result was not identical.

In FlashFXP the result would of been

0
00
000
000_A
000_Z
1
11
111
111_A
111_Z

I have adapted the logic in FlashFXP to take this into consideration and now sort 0's the same way as StrCmpLogicalW(), please give this updated dev build a try and see if it handles all your test cases correctly.

https://oss.azurewebsites.net/testr/ffxp-dev-build.zip

All test cases are now sorted properly, double checking with the "original" files still shows glitches. Since I cannot share the file names in public, is there I way I can email you a the list? My address should be in your customer files, so if you like feel free to get in contact with me and I'll send you a text file with all file names?