In Xojo, the Text data type is used to store and manipulate text strings, while the String data type is used to store and manipulate text strings of a specific character encoding, such as UTF-8 or UTF-16.
Text is a data type that is used to store and manipulate text strings in a platform-independent way. This means that the same text string can be used and displayed correctly on both Windows and macOS, for example, regardless of the underlying character encoding used by the operating system. Text strings are stored in memory as a sequence of Unicode characters, which are a standardized encoding of text characters that can represent most written languages in the world.
String on the other hand, is a data type that is used to store and manipulate text strings in a specific character encoding. These strings are stored in memory as a sequence of bytes, which represent the encoded characters. The specific character encoding used by the String data type depends on the platform, and is typically either UTF-8 or UTF-16.
In most cases, you should use Text when working with text strings in Xojo, as it provides a platform-independent way to store and manipulate text strings. However, in some cases, you may need to use String to work with text strings that are encoded in a specific character encoding.
It’s also worth noting that Xojo uses Text for the text fields and text areas in the GUI and String for the variables in your code.
–
it’s right i guess ? we can use mid and middle ?
I dunno what GPT is, but you should forget about the Text type altogether; it is now deprecated. Just use String, and the API2 methods such as Middle. I removed all Text from my app some years ago.
The Text type was deprecated in the past; and later, due to community claims, they changed it to “deemphasized use”. String absorbed all the unique Text type capabilities. So just use the String type.
A TextField holds a text content (letters, words, etc), that text content internally is a String. Maybe at some point some of those properties returned a Text type (not sure) before the “reorganization” around String. I do remember some classes containing Class.ToText() in the past that after the deemphasizing of the Text type gained a ToString() too.The idea is to kill the Text type in the future.
Assigning a string to the Text property replaces the entire contents of the control. The font, size, and color are uniform and match the values last set with the FontName, FontSize, and TextColor properties, or if these haven’t been used, the settings in the IDE.
Please note that the implementation of the DesktopTextField and DesktopTextArea controls is platform dependent. Do not expect that the text you assign is the same as the text you receive from this property. For example on Mac your text is converted to UTF-8 internally. On Windows all text after a null character (which means chr(0) and not “0”) is ignored. End of line characters can change to their platform specific counterpart. Special characters with Asc values below 32 may be ignored or removed.
Clear (remove) any text that is displayed in the TextArea:
TextArea1.Text = ""
This example places the selected text from a DesktopTextArea into a DesktopTextField.
When? When the dev commits an error? Are you trying to say the API1 was more lenient and accepted some silent errors and API2 is more strict and makes us more careful?
That would be the other way around, API2 would be more robust if it does not accept quietly something potentially harmful.
Var v As Variant
Var s As String
v = Val("A5")
// v = 0.0
v = Val("")
// v = 0.0
v = Mid("Hello World", 7, 100)
// v = "World"
// ---------------------
s = "A5"
v = s.Val
s = ""
v = s.Val
s = "Hello World"
s = s.Middle(6, 100)
// No exception was raised for any case
break
