carriage return

LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: carriage return

Post by FourthWorld » Fri Feb 23, 2018 4:00 pm

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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7215
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: carriage return

Post by jacque » 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. 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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: carriage return

Post by FourthWorld » Fri Feb 23, 2018 11:03 pm

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. ;)
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7215
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: carriage return

Post by jacque » 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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: carriage return

Post by bogs » Fri Feb 23, 2018 11:54 pm

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 :twisted:
Image

Post Reply

Return to “Getting Started with LiveCode - Experienced Developers”