Page 1 of 1
Carriage Return
Posted: Thu Apr 06, 2023 10:37 pm
by 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
Re: Carriage Return
Posted: Fri Apr 07, 2023 6:58 am
by richmond62
I must be very stupid, but as far as I can see the effect of CR or LF in a textField is identical.
Re: Carriage Return
Posted: Fri Apr 07, 2023 8:54 am
by 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.
Re: Carriage Return
Posted: Fri Apr 07, 2023 9:50 am
by 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
Re: Carriage Return
Posted: Fri Apr 07, 2023 11:04 am
by richmond62
Re: Carriage Return
Posted: Fri Apr 07, 2023 5:20 pm
by SparkOut
Cairoo wrote: ↑Fri Apr 07, 2023 8:54 am
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.)
Re: Carriage Return
Posted: Fri Apr 07, 2023 5:41 pm
by 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...
Re: Carriage Return
Posted: Fri Apr 07, 2023 11:57 pm
by 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)
Re: Carriage Return
Posted: Wed Apr 19, 2023 10:37 pm
by 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
Re: Carriage Return
Posted: Thu Apr 20, 2023 9:55 am
by stam
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…