I have a multi-line text input box in my form, when I save the document, I found that all “\r\n” in that multi-line input box changed to “\r”, it seem that DOMINO EAT my “\n”, why?
Subject: Why “\r\n” change to “\r” after I submit to domino?
Perhaps it was hungry 
Seriously though \n is the JavaScript for a line break/new line
Possible that it is being converted into a new line?
Subject: RE: Why “\r\n” change to “\r” after I submit to domino?
Do you literally mean the string “\r\n” or do you mean a carriage return followed by a linefeed? How do you know that this is happening? I know this may seem obvious to you, but remember we can’t see what’s on your screen, and there are many different ways to do things and many different places to look at data. What are you doing, exactly, and what are you seeing, exactly? How did you decide that the Domino web server is affecting your data, as opposed to the web page itself, or the method you’re using to examine the data?
And by the way, the value stored in a Notes field is a sequence of characters – not a binary file. The text data are converted to the character set we use (LMBCS). We have a way to represent a newline internally, which is the same regardless of which operating system the data came from. This is necessary since Notes is a cross-platform application.
If the above does not solve your problem, we need more information about what you’re doing. If you’re not sure what information to supply, the C R I S P Y document might help you.
- Andre Guirard, IBM/Lotus Development
Useful blog: Best Practice Makes Perfect
Subject: RE: Why “\r\n” change to “\r” after I submit to domino?
Yes, I means “a carriage return followed by a linefeed”
Is hard to say, So I make a picture, Please see:
img src=“http://www.winfreeinfo.com/multiline.jpg”>]
Hope for you reply!
Subject: RE: Why “\r\n” change to “\r” after I submit to domino?
When you type some text in a field, why do you think your pressing Enter is supposed to be represented by CRLF in the end data? Why would we waste a byte for each line – what benefit would there be from that? Do you have a way to use a LF without a CR, or vice versa? We’re not doing output to a line printer, after all.
The properties box is a good way to find out what’s stored in an item, but it’s not like your application reads the field value from the properties box. Different ways of reading the value may yield different newline delimiters. What’s the problem this is causing you? How it it keeping you from doing what you want to do in your application?
Subject: RE: Why “\r\n” change to “\r” after I submit to domino?
When you type some text in a field, why do you think your pressing Enter is supposed to be represented by CRLF in the end data?
I use JavaScript:
var i = document.forms[0].MultiLineText.value.indexOf( “\r\n” );
alert(i);
I can see the display value is not “-1”, so it means that “\r\n” is exists in MultiLineText field
In fact, the MAINSTREAM OS, like windows, always use “\r\n” to represent a new-line.
And, I found that if I use Lotus-Script to process this field value, “\r\n” will exists! See:
In Form’s WebQuerySave, run an agent
In agent, write code:
doc = session.DocumentContext
i = instr( doc.MultiLineText(0), Chr(13)+Chr(10) )
The result of “i”, is not “0”, it means that “doc.MultiLineText(0)” contains “\r\n” ! And why after document saved, the field value change to only “\r”??
Subject: RE: Why “\r\n” change to “\r” after I submit to domino?
Oh, sorry, I’d forgotten that Windows was the gold standard for all operating systems. The developers of UNIX – what were they thinking, making \n alone the line delimiter for text files? Those silly geese.
To test your assertion that something is different before the document is saved versus after, I wrote an agent that uses the debugStr function (which I’ve published in one of these forums) to display all the fields in a document (which has already been saved). Here’s the output, compared to the output in the properties box:
The properties box shows that the Subject field is 10 bytes, and there are 9 characters, so only one byte is used for the line delimiter (it looks like the display has been improved since version 7, so you can see where the line break is). However, when I request the value via NotesItem.Values, the value returned contains two characters there – CR and LF – just as in your Webquerysave agent. So, as I said before, a text value is not treated as a binary image of bytes; when you access it in your LotusScript code, it’s converted from LMBCS to a Unicode string, and apparently in the process the line delimiters are changed to CRLF – I’m not sure whether this works the same on all OS, or whether a locally appropriate value is returned. Also, when the value is displayed in the properties box, we can’t display raw bytes; it’s converted to a string that the OS knows how to use. You can’t tell what bytes are stored in the item by copying the displayed value to the clipboard; they’re not necessarily the same. You would have to use the C API to read the original bytes, to see how the value is really stored. The program Notespk does this; here’s from the same document viewed with Notespk:
The line delimiter used internally for storage is NULL character, \0.
In any case, there’s nothing here to indicate that anything changed when the document was saved. And I ask again, what problem does this cause you?