I would like to sort files and folders EXACTLY the way File Explorer does on Windows 10.
Gone through a number of example programs from the forum but they do not work exactly.
Apparently File Explorer calls a function called StrCmpLogicalW.
Is there a way I could call this function from LabVIEW?
Appreciate any suggestions on how this can be done with LabVIEW.
Solved! Go to Solution.
There is of course, with the Call Library Node. But as the W at the end of the name indicates, does this function use Unicode strings while LabVIEW strings are ANSI. So you would have to convert every single file name with the function MultiByteToWideChar() first. This will get somewhat complicated to to yourself but fortunately there are functions in this thread, that do this already. You probably want to download and install the ni_lib_unicode_126.96.36.199.vip file from that list.
However it would be possible to create a similar comparison function fully in LabVIEW. The magic is to recognize numbers as whole numbers and sort the strings first alphabetically and if the part up to the number is the the same compare the numbers as whole instead of alphabetically.
Thank you rolfk.
Following your first paragraph, do you have an example on how should I convert the ANSI to Unicode then parse this into the Call Library Node?
Can anyone show me how to feed this converted Unicode string into the StrCmpLogicalW function in the Call Library Node?
It's as "simple" as this (but the used ASCI to UTF16 function is of course Windows only too, but logically correct unlike the other proposed solution which will fail for any ASCII code point above 127):
Thank you rolfk .
Can you please elaborate more on your statement "but the used ASCI to UTF16 function is of course Windows only too, but logically correct unlike the other proposed solution which will fail for any ASCII code point above 127"?
Since my VI uses a Call Library Node to call a Windows API, it won't be possible to execute it on non-Windows LabVIEW platforms.
The function as proposed by bseguin does convert the ASCII codes into pseudo UTF16LE by converting all the ASCII codes 0x00 ..0xFF to 16 bit code points 0x0000 ... 0x00FF. That is only correct for the 7-bit ASCII codes 0x00 ... 0x7E. Above 0x007F the mapping between ASCII and Unicode is not the same anymore. Windows Latin-1 (codepage 1252) uses with some exceptions the same extended characters as ISO IEC8859-1 but is not the same. But if your configured local is not using Latin-1 then this mapping gets for those extended ASCII codes completely wrong.
Rolfk, this is excellent support. Thank you.
Your code works intermittently at times.
When I set String 1 to 1.1 and String 2 to 1, I will get a return value of 1 (this is correct).
But then I set String 2 to 1.1 (equal to String 1), I get a return value of -1 (it should be 0).
After this when I set String 2 back to 1 (same as the first step), the return value will now change to -1 (it should be 1).
Do you know why this is happening?