Bug in ReplaceAll?

[Michael_Bzdega]

ok, thank you.

[Michel_Bujardet]

With the Text type, replaceall is simpler :

dim t as text = name.ToText t = t.ReplaceAll("","ae") name = t msgbox name

[Joe_Ranieri]

@169296:@Michael Bzdega

Thanks very much for the explanation, Joe. The solutions Michael provided above works like i need it. But i want to understand where i can find the characternumber like michael posted with chr(776) for the second part of the ä. Where do i have to search to find what an ö is made of (o and some chr(?)).

776 is the decimal representation of the hexadecimal 308 (as in U+0308 COMBINING DIAERESIS). In Unicode, all combining characters follow the ‘main’ character, meaning that it doesn’t differ for ö, ä, or ë when they are in their decomposed form. Wikipedia has a decent table for combining diacritical marks, or it could be found in the Unicode specification (not for the faint of heart).

Again, if you use Text, you get to ignore all of this :).

[Michael_Bzdega]

yes. already discovered, that the second part of every is the same. &hCC or chr(776).

Now i will try text to find out that all of this long discussion can be managed by this simple convertig to text… which i asked before. Is nobody reading my posts?

Just kidding. Don’t get me wrong. Thanks to all.

Michael

[Michael_Bzdega]

The converting-to-text-method works fine.

      'System.DebugLog("f.Name: " + f.Name)
      
      dim tempAttachmentName As Text = f.Name.ToText
      
      tempAttachmentName = tempAttachmentName.ReplaceAll("", "ae")
      tempAttachmentName = tempAttachmentName.ReplaceAll("", "oe")
      tempAttachmentName = tempAttachmentName.ReplaceAll("", "ue")
      
      'System.DebugLog("tempAttachmentName: " + tempAttachmentName)
      
      attachment = new EmailAttachment
      attachment.LoadFromFile(GetFolderItem(f.NativePath, FolderItem.PathTypeNative))
      attachment.Name = tempAttachmentName
      
      'System.DebugLog("attachment.Name: " + attachment.Name)

[Markus_Winter]

So how would you properly normalize if you have to stay with string for backwards compatibility?

Sure I could write a replace function for every composed character (following Michel’s lead), but is there a more elegant way?

[TomE]

[quote=169347:@Markus Winter]So how would you properly normalize if you have to stay with string for backwards compatibility?

Sure I could write a replace function for every composed character (following Michel’s lead), but is there a more elegant way?[/quote]
See my previous mail. It leads to a reference to the OS provided “CFStringNormalize” call.
That is actually the elegant way.

Edit:
And I did forgot: No plugin needed!

[Markus_Winter]

@169363:@Thomas Eckert

The declares into “Carbon.framework” are misleading. Those functions actually live in “CoreFoundation.framework” and the declare works only because Carbon re-exports the symbols from CoreFoundation. The “Normalize” function in the post will keep working in the future, even in 64-bit applications.

Thanks, I read it.

I also read Joe’s reply:

The declares into “Carbon.framework” are misleading. Those functions actually live in “CoreFoundation.framework” and the declare works only because Carbon re-exports the symbols from CoreFoundation. The “Normalize” function in the post will keep working in the future, even in 64-bit applications.

So in other words: what is the proper call to CoreFoundation?

[Joe_Ranieri]

@169378:@Markus Winter

So in other words: what is the proper call to CoreFoundation?

Just change the library name from “Carbon.framework” to “CoreFoundation.framework”.

[Markus_Winter]

Thanks Joe.