View Single Post
  #2  
Old March 27th 16, 11:06 PM posted to microsoft.public.windowsxp.help_and_support
VanguardLH[_2_]
external usenet poster
 
Posts: 10,881
Default Explorer filename sorting - disable ignoring of the hyphen ("-") char ?

R.Wieser wrote:

My previous subject "Explorer filename sorting problem - NoStrCmpLogical
already present" has evolved into a much simpler one: How do I get XP's
explorer (but the "dir" command too!) to stop ignoring the minus sign inside
filenames

60.00.00.32.dds
60.00.00.32.msh
60.00.00.32.nif
60.00.32.32.dds
60.00.-32.32.dds
60.00.32.32.msh
60.00.-32.32.msh
60.00.32.32.nif
60.00.-32.32.nif

the reason why the above is "sorted" as it is -- with the third column
showing an interleaved "33" and "-32" -- is because the minus sign is
regarded as a hyphen (a word-coupling character) and ignored. The above
list than translates to:

60.00.00.32.dds
60.00.00.32.msh
60.00.00.32.nif
60.00.32.32.dds
60.00.32.32.dds
60.00.32.32.msh
60.00.32.32.msh
60.00.32.32.nif
60.00.32.32.nif

... which makes (some sort of) sense.

But as those "-" characters inthge first list are *NOT* hypens (but
minus-signs) that second list isn't reflecting the meaning of the filenames
contents. :-(

tl;dr:
How do I get XP's explorer (and "dir" command too) to stop ignoring the
minus sign inside filenames.

Or more in general: How do I stop it from treating *any* character
specially, and just sort all of them on their binary value.

Regards,
Rudy Wieser


In text strings, there is no such thing as a number, even less so a
negative number. With NoStrCmpLogical, there is no such thing as a
number in a text string; i.e., sorting is ASCII order. The smart
ordering would interpret a numerical *character* (or contiguous
substring of them) as having a numerical value; however, I doubt smart
ordering considers any scaling prefixes (+ or -) as numerical modifiers
but just simple ASCII (alphabetic) characters. That a number or series
of them are in a string won't be known until the + or - have already
been passed over.

How would a parser looking at a text string discern a subtring of
characters represented a number? By trigging on the first instance of a
numerical character. If it triggered its parsing to include the + and -
characters, what would it do with "abc--def" versus "abc-0-def"?
Perhaps it could require that a + or - be immediately followed by a
numerical character to include the + or - in the numerical value but
what would it do with "abc-4+5-def"?

You see them and want them to be signed numbers. Somehow parsing has to
determine the same thing. A boundary has to be detected to determine
when there is a substring that could be interpreted as a number. A
trailing hyphen after non-numerical characters won't trigger that the
next character must be a numerical character. Not until the 3 is
reached during parsing would it be known that the prior hyphen meant a
negative number was in the string; however, that would require the
parser to move backward after finding the first numerical character.
That's doable in code but probably not present in the filename parser.
Most parsers don't like to or cannot move backward (unless they provide
a buffer, like a variable, to track backwards).

Do it yourself. Take a piece of paper with a cutout the size of just 1
character. Start moving the hole across a long string. When do you
know that there is an ASCII character that could represent a number?
The first time you hit a character in the range of "0" to "9". You have
already passed any hyphen or plus character before you can switch to an
interpretation of numerical value as a substring. Parsing usually just
moves forward.

If you want to emulate numerical ordering based on substrings within a
text string then make sure to use characters in the same columnar
position that will effect that ordering. + (43) sorts before - (45).
Stop using non-signed numerical strings to represent a positive value.
If some substrings are going to be interpreted as numerical then ALL
substrings must be signed. +32 will sort before -32. If you don't want
to show a + character for positive values then use a space (so the
numbers align in the same column); however, adding spaces into filenames
runs into other parsing problems, like you forgetting to enclosed a
filename with spaces by using double-quotes. Alas, if you want sorting
to be in signed numerical order with negative values listed before
positive values, this trick won't work. You will need to use a
substitute character for + that sorts after -, like = (61) or ~ (126).
Ads