I have, in my constants when saved as text. But thought that only the IDE / Compiler accepted that for loading but at the programming level it wasn’t acceptable and would end as an error. That’s a kind of C string escape sequence. I discovered it when I pasted a multiline string ending lines with chr(10) presenting malfunction and in the code I’ve saw things as “Line 1\rLine 2\r” showing that the IDE changed my new-lines by carriage-returns. And yes, \r, \n works too.
When a string is prefixed with the \ character, Xojo treats the string as a C String Literal, all standard String Literal rules apply. This is currently undocumented but I’ll add something about it now.
That seems like an unwise gut-reaction choice since the newline ability breaks syntax coloring and is very obviously not supported by the IDE. Fix the IDE support before making official documentation.
Sorry, no, \xXX represents bytes so \xXX\xYY would insert two bytes, not the code XXYY. You’d have to figure out the bytes behind that encoding and insert those manually, and that’s not great.
But this is a minor challenge and, after the feature is documented, I’ll start a ticket to get support for \uXXXX and \u{YYYY}.
Well it exists, and has existed since the time when there was actually a compiler engineer, solely for the IDE to deal with encoding things in text projects. I’d rather see Xojo flesh out features and implement them completely. This trend of rushing to release and document it as “incomplete” is not what I consider quality software.
All those years writing code like this:
var s as string = “like” + Endofline + _
“that”
And years from now you will still understand what that code is doing.
But if you take advantage of:
var s as string = "this
that" // Works!
Sometime in the future, something might be moved - and extra space, an extra Return, and s will be different and I’m guessing it will be a heck of a problem to track down.