Carriage Return

[Cairoo]

Dear fellow LiveCode users,

Just to help prevent some of you getting a bit confused as I have, please note that at the time of my writing this post, the word "CR" in LiveCode does NOT mean control character 13. Even though CR is supposed to mean "Carriage Return", the LiveCode engine has CR meaning the same thing as LF (Line-feed), which is control character 10. Keeping this in mind may save you some headaches when working with text data.

Gerrie

[richmond62]

I must be very stupid, but as far as I can see the effect of CR or LF in a textField is identical.

[Cairoo]

Their effect is identical precisely because CR and LF in LiveCode have been defined as control character 10, even though they were supposed to be different.

[richmond62]

Oddly enough CR and LF seem to have been conflated:
-

-
Yet it is perfectly possible to do this:

Code: Select all

on mouseUp
   put (CR & "x") after fld "ff"
end mouseUp

or this:

Code: Select all

on mouseUp
   put (LF & "q") after fld "ff"
end mouseUp

but a quick-n-dirty codePointToNum for both those does return 10.

If you do this sort of thing:

Code: Select all

on mouseUp
   put empty into fld "ff"
   put ((numToCodePoint(13)) & "x") after fld "ff"
end mouseUp

the result looks like SPACE + 'x'.

I would suppose the reason for CRLF is to keep Windows users happy:
-

-
https://stackoverflow.com/questions/155 ... reak-types

[richmond62]

[SparkOut]

Their effect is identical precisely because CR and LF in LiveCode have been defined as control character 10, even though they were supposed to be different.

I'm not sure that is the strict definition of what is going on, although on the surface it appears that way.
LiveCode will work internally with line endings as char(10) but for cross-platform purposes, will adjust any text output (ie not binfile:) to use the standard as applied on the platform in use.

So if you

Code: Select all

put "line 1" & cr & "line 2" into tText
put tText into url ("file:" & specialFolderPath("documents") & "/test.txt"

on Windows you csn examine the file contents and discover "line 1<CRLF>line 2" and on Linux "line 1<LF>line 2" and on Mac you'll get whatever the Mac OS version standard is. (I think it used to be <CR>, ie CHR(13) but I sort of heard they might have changed the standards- but I'm not a Mac user, so not really sure.)

[stam]

If the standard newline char is giving you issues:
Since the regex \R token (capital R) will find all possible variations of a line ending, you could simply run

Code: Select all

replaceText (<container>, "\R", "<my newLine ascii char of choice>") 

to clean up any imported data and/or export data in appropriate format...

[bwmilby]

Very correct. Internally, RETURN, LINEFEED, LF, and CR are synonyms that all evaluate to ASCII 10. It does not really matter when within LiveCode though (text in fields). When you import text into LC, the line delimiter is changed to 10 and that is what LC uses. When you save text, the value is changed depending on platform. For Linux you get 10, for Windows you get 13+10, for Mac you get 13 (but should change to 10 in the v10 update cycle).

If you are processing text files and the source line ending is important to retain, then you need to open them as binary and store in variables (also need to handle UTF decoding with textDecode)

[FourthWorld]

The CR constant has been such a common FAQ some years ago I wrote about on LiveCode Journal, with background on how it got that way and tips for working with it:
http://livecodejournal.com/features/liv ... dings.html

[stam]

The CR constant has been such a common FAQ some years ago I wrote about on LiveCode Journal, with background on how it got that way and tips for working with it:
http://livecodejournal.com/features/liv ... dings.html

Thanks for the URL Richard - a good read indeed.

More importantly I had never come across LiveCode Journal before, in spite quite a bit of Googling for LiveCode resources, I’ll definitely spend some time delving in it.

There seem to be many resources that appear abandoned and much of the useful stuff that may still valid just doesn’t seem accessible, which is a loss…