ToText deprecated

General
1

u.name is a string property of a Class represented by “u”

Porting to the new API, the old code was:

elseif u.name.toText = "Blücher" then

Xojo does not accept changing it to:

elseif u.name.toString = "Blücher" then

If comparing the strings directly:

elseif u.name = "Blücher" then

the strings don’t match. This issue occurs after saving/loading from an SQLite database. Using toText again and ignoring the deprecated warning makes it work. This is likely an encoding conflict with the “ü” character probably…

2

Perhaps not surprising as u.name is already a String.

How is the value of u.name set? What encoding shows up if you examine u.name in the debugger?

3

UTF-8

4

Have you compared the bytes in your string with the bytes in u.name, by eye? In the debugger?

One might be:

U+00FC ü c3 bc LATIN SMALL LETTER U WITH DIAERESIS

the other might be:

U+0075 u 75 LATIN SMALL LETTER U
U+0308 ̈ cc 88 COMBINING DIAERESIS

so, two bytes (c3 bc) vs. three bytes (75 cc 88).

(Assuming this is what is meant by combining).

5

But, what does ToText that make this work?

u.name = "Blûcher" // no work
u.name.toText =  "Blûcher"  // works
6

Text is not the same as String. The compiler probably converts your “Blücher” to Text automatically.

Anyway - have you compared them in the debugger?

7

the debugger shows the name correctly
image

image
image1282×224 22.5 KB

8

I suggested to you to compare the bytes.

But as I suspected, the bytes involved are 75 cc 88. These are the bytes from the database. Which will not compare to c3 bc.

Anyone know how to force this to work?

9

Basically your problem seems to be that the data in the database uses non-composed characters, whereas Xojo is assuming composed characters.

The ü is not composed, in the database - it’s a simple u followed by a composing umlaut (so, two code points, 3 bytes), which will appear the same on-screen as the single code point ü (two bytes). How did the data get into the database?

10

This may be your answer:

11

If I display the u.name, for example:

mylabel.text = u.name
it is showed “Blücher” ok, is when comparing that it not works

12 
var  source as string  = "Blücher"
if u.name = source then
  break
end if

in the debbuger
Source shows in Text as “Blücher”
In Binary as

image
image1054×162 15 KB

u.name show in Text as “Blücher”
but in binary

image
image1054×162 15.4 KB

13

Right, that’s exactly what Tim has been explaining: those two strings appear the same when printed to the screen, but the underlying bytes are different, and thus the string compare function isn’t behaving as expected.

Go follow that link that I posted and download the Unicode module. Normalize both of your strings and then compare them; you should find that they compare properly.

14

Honestly I think this is a flaw in how strings are compared, whether that’s in the Unicode specification; the OS’s implementation; or Xojo’s internal implementation. Decomposed characters should equate to their composed representations. I don’t know why it is done this way.

15

Where is the Unicode module?, please.

16
17

May it be considered a bug?
Made the following test::

var enc as TextEncoding = u.name.Encoding
var  source as string  = "Blücher"
var enc2 as TextEncoding = source.Encoding

source = source.DefineEncoding(enc)

if u.name = source then
  break
end if

enc and enc2 show the same on the debbuger

Pasted Graphic

But the string comparetion fails

18

The STRING data type has never implemented all of the Unicode rules.

You could try the STRING Compare function to see if that helps but you may find that you need to log an enhancement request.

FYI. The TEXT data type should compare them correctly but that data type is no longer recommended.

1 Like
19

From the documentation:

image
image1342×412 20.3 KB

20

This works

elseif u.name.Compare("Blücher") = 0 then
1 Like