String comparison works on Windows but not on OSX

I have some code in a function that does a simple string comparison.

If stringa = stringb then …

What’s puzzling me is that when I run on Windows the function finds the match, but on Mac it doesn’t. When stepping through the program the strings look identical. Could it be that the Mac adds some kind of invisible end of line type character to the string?

Checking the binary values of both strings they are identical. They should be identical. To windows, they are identical. To Mac, they aren’t.

I decided to make the check work with a different kind of loop, and then suddenly it worked. I’ll post the two variants below. Does anyone have any idea why one would work and the other not? In my mind, they are identical. The only difference between the code below and the code in my project is that the strings are memebers of a class.

Works on Mac and Windows:

[code] Remove(input as string)
dim i as integer

for each s as string in aStrings

if s = input  then
  
  try
    // then remove it
    aStrings.remove(i)
    return true
    
  catch
    // there was some kind of problem
    setLastError "unable to remove string"
    return false
    
  end try
  
end if

i = i + 1

next

// return false to show that we were unsuccessful
setLastError “unable to find string”
return false[/code]

Code that works on Windows but doesn’t work on Mac:

[code] dim i as integer
dim size as integer = UBound(aStrings)

while i < size
// if the string matches the string in the array
if aStrings(i) = input then
try
// then remove it
aHotkeys.remove(i)
return true
catch
// there was some kind of problem
setLastError “unable to remove string”
return false
end try
end if

i = i + 1

wend

// return false to show that we were unsuccessful
setLastError “unable to find string”
return false[/code]

I haven’t tried the code in a fresh new project. But if it works in a new project, my next question would be: why? Maybe this is some kind of complex bug. I don’t know.

Instead of aStrings(i) = input try using StrComp to compare the two strings and see how that works.
Xojo Docs - StrComp

Alarmingly it is no better using StrComp. Still doesn’t work on Mac

Where do you get the strings from?
In case they come from a Folderitem: are there funny characters like Umlauts in the string?

In that case it could be a composite vs. decomposite string issue. On the NUG Charles Yeomans wrote 5 years ago:

[code]For Mac OS, you can use some Carbon functions to normalize the data. I think I’ve posted code to the mailing list – found it.

Function Normalize(s as String, form as UInt32) As String
if Encoding(s) is nil then
return s
end if

#if targetMacOS
soft declare function CFStringCreateMutableCopy lib “Carbon.framework” (alloc as Ptr, maxLength as UInt32, theString as CFStringRef) as CFStringRef

dim mutableStringRef as CFStringRef = CFStringCreateMutableCopy(nil, 0, s)

soft declare sub CFStringNormalize lib “Carbon.framework” (theString as CFStringRef, theForm as UInt32)

CFStringNormalize mutableStringRef, form
return mutableStringRef
#endif

'enum CFStringNormalizationForm {
'kCFStringNormalizationFormD = 0,
'kCFStringNormalizationFormKD = 1,
'kCFStringNormalizationFormC = 2,
'kCFStringNormalizationFormKC = 3
End Function
[/code]

The strings are made internally by me - not from outside. They are supremely simple and only consist of ASCII chars (no umlauts or fancy characters). Strictly a-zA-Z and a + sign. They form a hotkey so the typical string looks like:

“ctrl+c” or “ctrl+alt+home”

There’s no end of line characters or anything like that. But the bizzare thing is that it seems to not be the comparison (I use the same comparison in both methods) but the loop. It will work with a for each but not with a while. An array element isn’t missed because i is always identical in both loops.

I’m not so worried because I can use the for each loop and it works, but it just makes me wonder what’s going on.

Thanks for the replies by the way.

I tried it running natively (not through remote debugger) and both work. So I dunno. Maybe it’s a freak bug with the debugger…