I think the result would not be 0. Note that (TpTextA = TpTextB) is False.
The result is 0 except with ch(9), chr(10), chr(11), chr(12) and chr(13).
I made a small exemple, click ButtonA and ButtonB . Test-CompareString
I would like to know if it’s a bug or not, if I have to fill a bug report.
If a string has a control character and the other string does not, then the compare string should not be 0, shouldn’t it?
I test (MyStringA = MyStringB) and (MyStringA.Compare(MyStringB, ComparisonOptions.CaseInsensitive) in order to obtain the result I want.
The documentation is completely opaque as to how ranking is determined by string.compare, i.e. how does it decide if one string is “greater than” another. The example tells us that “dog” > “cat” but not why. In your example, maybe it gives equal weight to Chr(32) and Chr(31).
Looks like it takes the first char of each and compares their ASCII values, then moves to the second char of each, until either it gets a less/greater result for a pair of chars, or runs out of chars in one string. BICBW.
Comparing strings that represent numbers with prefixes and suffixes is always a pain, I’ve written my own compare function, but it too has trouble with phrases that contain a mix of letters and numbers. I was hoping that Xojo’s text compare would have a way to sort the way people do, not machines.
I’m not sure what magic Xojo (or any language) could do for your here. It would seem like the rules for sorting/comparing such combined data would vary by its purpose.
However, you can create your own comparers/sorters with Xojo. So if you had a string value that actually consisted on multiple parts that were concatenated, such as “C9999cats999”, then you could instead create a class with properties for each part:C, 9999, cats, 999.
Put your values in class instances and then implement your own Operator_Compare() method on the class to allow you to compare all those properties in the way that makes sense for you.