From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
File Explorer Sort
Solved!
Perfect!.. I can now just implement this into a sort algorithm correct (e.g bubblesort / quicksort)?
FYI the Sub VI to Convert ASCII to UTF-16LE in the ni_lib_unicode_2.0.0.4.vip package also does not work. The code is different from your SubVI though.
Forum saying there was an error when posting and to try it again and when doing so, ended up with double post.
@Sable wrote:
Perfect!.. I can now just implement this into a sort algorithm correct (e.g bubblesort / quicksort)?
Yes
FYI the Sub VI to Convert ASCII to UTF-16LE in the ni_lib_unicode_2.0.0.4.vip package also does not work. The code is different from your SubVI though.
The problem is that this function is not really working properly because it does not provide enough space for a terminating NULL character in the Unicode string. I made that error too in the first version but I use the Windows API more in the way it was designed where the string is first prescanned to let it find the necessary length of the UTF buffer. The ni_lib function could be made to work MOST of the time by adding an increment by 1 in front of the multiply by 2 node. I say MOST here because there is a possibility that Unicode does not encode an ANSI character for certain codepages into a single 16 bit Unicode code point. That chance is pretty small since this function is called with the PRECOMPOSED flag but it is still not entirely 0 for exotic codepages.
@Sable wrote:
I guess there are some bugs in the ni_lib_unicode_2.0.0.4.vip which should be noted. Future users may encounter the same issue.
It's debatable if this needs to be declared as bug. The function generates a LabVIEW byte array that contains the Unicode string but represents it as a LabVIEW string. As such it is not an ideal representation but fully valid since the LabVIEW string does contain the length of the byte array already, without the need to add a NULL character to the end. The problem happens when you pass this "string" to a Windows API function without the possibility to also pass it the explicit length of the string as extra parameter. The Windows API will then scan the string for the NULL termination character but there is no guarantee that the two bytes after the end of the LabVIEW byte buffer will be zero. So the function scans past the end of the actual buffer and considers that also as part of the string. Basically the string returned by the ni_lib_unicode function was never designed to be passed to Windows API functions that do not allow to specify an explicit length of the string buffer.
Representing the UTF16 string as LabVIEW 8-byte string is definitely not ideal at all, but can be convenient for some situations. Representing it as 16 bit integer array as I did is definitely more correct but it makes the string more difficult to view at runtime as numeric arrays have no ASCII interpretation mode, while LabVIEW strings can be viewed either as hex display (numeric), normal text, backslash code (and password display which is irrelevant for this use case).
In this case, is the execution time faster, slower or the same when using the Call Library Node compared to fully in LabVIEW?
That depends on how you implement it. The first step would be to get a comparison VI that does actually have the same functionality. This will be some work especially if you want to make sure that it behaves exactly the same. Your first few attempts will likely be naive and not have the same result. Once you have something that seems to work you might need to do extensive testing to make sure it does the same even in corner cases, though I would guess that exact 1 to 1 operation might not be the most important as long as its compare result is the same for most common situations.
Then you can start doing performance checks. I would guess that a naive but correct implementation in LabVIEW will tend to be slower but there is absolutely no reason that a well implemented pure LabVIEW function needs to be slower at all. For one you do need to convert each string to Unicode first which will take some execution time too, and that is completely unnecessary for a pure LabVIEW implementation. But unless you do a very naive implementation there is no reason that a LabVIEW implementation would need to be magnitudes slower than the Windows API solution.
I would guess that the general approach to implement this in a fairly good way would be to do a character by character comparison first without case sensitivity. As soon as you detect that both characters are numbers you need to convert the rest of the string as far as possible into a number and then compare that result. Then resume comparing characters case insensitively starting from the new offset after both numbers until you encounter another number.
