The strings are UTF8 by default and so I’d just use it. See my previous link for details about the normalize function.
Just make sure that each name from a FolderItem is normalized before it is used. 
Yes I did, it’s the same except that you pass form as parameters in the method. I don’t know what it is and by default I put 2 as you did in your TextArea exemple.
I edit my function code in my post above.
I still don’t understand why it is not necessary to convert CeTexte in UTF8 as if I do :
' MessageBox str(CeTexte.Bytes) + " - " + str(CeTexte.ConvertEncoding(Encodings.UTF8).Bytes)I have a different result, then it’s not the same? Or does Xojo convert itself the string in UTF8 before send it to the declare function?
Since I do always use UTF8 I did not investigate this. Perhaps the Xcode help for the declare calls may help.
I still fail to see how all this prevent you from installing Catalina in a virtual machine and do your tests there
macOS has always had issues with normalisation when comparing strings and filenames. We have code dating back to 2012 that uses CFString to solve this.
From what I can remember, the switch from HFS+ to APFS changed how filenames are stored but im sure you still need to normalise when comparing with strings.
I would be surprised if Apple have changed the rules again for Catalina as that would mean drives with the same file system type could have different filename normalisation rules which would cause no end of problems everywhere.
Maybe Catalina is a red herring here. I guess you also cant rule out a bug in Catalina since it is a bit of an omnishambles.
Full ACK.
Kevin, some users using Catalina report bug I don’t have under Mojave. With my sync program, an user delete the incriminated folder in the Target folder. Then the folder was copied by my program (using Xojo MyFolderItem.CopyTo ). Then he relaunch the Sync and my program see a difference between the two names.
Then I don’t know if it’s Xojo fault or Catalina fault. But a folder names “rtyi” in folderA which is copied in folderB using .CopyTo return False to the test : MyFolderA.Child(“rtyi”).name = MyFolderB.Child(“rtyi”).name
Arnaud, I did use Parallels long time ago but I don’t have anymore license. I may instal Catalina on an external disk but restart each time 
.
Thomas, virtualbox is free to use.
https://www.virtualbox.org/
also useful : https://www.tech2tech.fr/comment-installer-macos-catalina-10-15-sur-virtualbox-sur-windows/
[quote=489489:@Thomas ROBISSON]Kevin, some users using Catalina report bug I don’t have under Mojave. With my sync program, an user delete the incriminated folder in the Target folder. Then the folder was copied by my program (using Xojo MyFolderItem.CopyTo ). Then he relaunch the Sync and my program see a difference between the two names.
Then I don’t know if it’s Xojo fault or Catalina fault. But a folder names “rtéyöi” in folderA which is copied in folderB using .CopyTo return False to the test : MyFolderA.Child(“rtéyöi”).name = MyFolderB.Child(“rtéyöi”).name
Arnaud, I did use Parallels long time ago but I don’t have anymore license. I may instal Catalina on an external disk but restart each time .[/quote]
Could it have something to do with how the drive is formatted (HFS+ vs APFS)?
Are the source & target folders on the same drive? (maybe this occurs when the source and target folders are on different drives which have been formatted differently)
The normalisation issues we had to workaround were neither the OS or Xojo’s fault. If I were to blame someone I would choose Unicode themselves for allowing the same character to be represented in multiple ways.
I also think you might have been lucky not to have hit this already. As I mentioned previously, we had to address it 8 years ago when part of our application compared filenames.
One of the guy who reported bug told me that he created 2 tests folders in his Documents folders of Home folder in his SSD drive.
The problems describe above seem to have disappeared with Xojo 2020r1 .
1 Like
In fact no, I still need to use the NormEncoding.