LiveCode Forums

Klaus wrote: ↑

Fri Feb 23, 2018 3:34 pm

bwmilby wrote: ↑

Fri Feb 23, 2018 3:18 pm

Numtochar does always return what is asked for.
Put Chartonum(numtochar(10)) —> 10

Yes, this still works, although it (numtochar/chartonum) has been deprecated since version 7!

Only in the most limited sense of "deprecated", and for reasons unrelated to line endings.

The original use case for those functions was to convert a character to an ASCII value or vice versa. Fine for the first couple decades of personal computing, but of course useless in the modern Unicode world.

For those who had been relying on them to derive integer values from a single byte, v7 and forward include byteToNum and numToByte.

For those wanting to know the numeric value of a character within Unicode, we now have codePointToNum and numToCodePoint.

And for the subset of people working with ASCII data, charToNum and numToChar continue to work, and AFAIK there's no plan to remove them. Scripters are merely cautioned against using them for the same scope of use cases they were originally created for, since Unicode has required the engine team to add those new alternatives which will usually do a more reliable job with modern encodings.

It's very simple:

CR should always mean Carriage Return (ASCII 13)

LF should always mean LineFeed (ASCII 10)

return means either, as adjusted to suit the platform

NumToChar() should always return the char. as specified by the ASCII number used

I just want to point out that all four of these work as expected in LC. You can test this by using the constants in some text in a field. Substitutions only occur when importing or exporting data from outside sources. This usually involves files or internet data, but browsers are also an external source.

LC provides specific ways to deal with this. For files, when using the URL container, the "file" keyword will do substitutions, the "binfile" keyword will not. (Or you can use an alternate method: "open file for binary read|write|both", etc.) Unicode has similar requirements, in that we need to use textEncode and textDecode to move unicode data in and out of LC. For browsers, as you're working with, you can set the line endings specifically.

This gives the best of both worlds, as long as you know that LC will try to "help" unless you specifically tell it not to.

jacque wrote: ↑

Fri Feb 23, 2018 10:31 pm

It's very simple:

CR should always mean Carriage Return (ASCII 13)

LF should always mean LineFeed (ASCII 10)

return means either, as adjusted to suit the platform

NumToChar() should always return the char. as specified by the ASCII number used

I just want to point out that all four of these work as expected in LC....

...with one exception: internally, LiveCode (no doubt due to its Unix origins) uses ASCII 10 for CR.

That seems to be the main complaint, and if we didn't have 30 years of people using return and CR as synonyms I'd agree. But under the circumstances, we'll just consider this the LiveCode equivalent of Python's sensitivity to white space, or LISP's parantheses addiction.

...with one exception: internally, LiveCode (no doubt due to its Unix origins) uses ASCII 10 for CR.

Oh right. I guess I'm an apologist after all. I can't help it.

jacque wrote: ↑

Fri Feb 23, 2018 11:15 pm

...with one exception: internally, LiveCode (no doubt due to its Unix origins) uses ASCII 10 for CR.

Oh right. I guess I'm an apologist after all. I can't help it.

I can help you with that, I'm going to enroll you in the "Sal-Monella" course for apologists