Subject: Ugh! Passing \n and \r to Notes fields through Java
The ONLY thing we could do for a workaround was to:1) complete all the processing in the Java agent
put some unique string (say “~^~”) where we really wanted a line break in the text fields.
save the document
pass the NoteId of the document as a parameter in a agent.run command where the agent is a LotusScript agent that simply replaced the ~^~ with chr(10) and saved the document.
One extra save command, but if anyone else has a better workaround, please pass it on.
Has anyone had any joy with this issue. I’m developing a front end with Java to access a Domino db that we bought from an IBM business partner so I have no control over template design.
The development was going well until I updated a computed text field on a form that contains action history. I formatted my entry and replaced the field value. The web client displays the field properly but the notes client removes all carriage returns and line feeds. If the document is opened and edited in the client the field formats properly. Obvisouly nothing new here after reading this thread.
Updating this field is one of the most important actions in my application. Does anyone have any further information on this issue? Is this a bug that should be reported?
Subject: SOLUTION: Ugh! Passing \n and \r to Notes fields through Java
Hi,it might not be the best solution however the best workaround.
First thing: In java ever add \r\n as newline. The properties box will show it right if you are browsing in a view. To let the field show up with it newlines in a form you have to add a “helper” field.
Example:
Your field within the newlines is body. Then add an field which is editable, named like: body_helper, with the following properites:
Thats all. If you save the form with CRTL-S the field will be empty. This is not quite pretty. Avoid this by adding:
POSTSAVE:
FIELD body_helper := @ReplaceSubstring(body;@Char(10) + @Char(13); @NewLine) ;
Done.
BTW: if you only want to display the body field with its embedded linefeeds and you dont need to mark the text for cut and pasting you can use a computed value field. This one will show the newlines in a propper way.
Yes this works but not the straight forward way. The steps to success are,
1). Have a hidden Computed ‘temp’ field which is a ‘Text’ Single value field. This is the field updated from Java process with the new value that needs to be appended to ‘target’ field.
2). Have the main Computed ‘target’ field named ‘history’ (for discussion) which is a Single Value ‘Text’ field.
3). Do ‘computeWithForm()’ method in Java to compute the field formulaes and save the document.
The formula for both the fields is,
temp field: @If( temp != “”; “”; “” )
history field:
newVal := @If( temp != “”; history + @NewLine + temp; history );
newVal
Have the JAVA code to update the ‘temp’ field and the computed history field will have the value as expected separated by new line…
Yes this works but not the straight forward way. The steps to success are,
1). Have a hidden Computed ‘temp’ field which is a ‘Text’ Single value field. This is the field updated from Java process with the new value that needs to be appended to ‘target’ field.
2). Have the main Computed ‘target’ field named ‘history’ (for discussion) which is a Single Value ‘Text’ field.
3). Do ‘computeWithForm()’ method in Java to compute the field formulaes and save the document.
The formula for both the fields is,
temp field: @If( temp != “”; “”; “” )
history field:
newVal := @If( temp != “”; history + @NewLine + temp; history );
newVal
Have the JAVA code to update the ‘temp’ field and the computed history field will have the value as expected separated by new line…
Subject: Thanks for all the responses… here’s my workaround.
I know this may not work is all scenarios but I was able to incorporate the information I needed displayed into a layout region’s text field. For some reason this field is very forgiving when displaying newline characters.
Subject: ON NO!!!.. re: Thanks for all the responses… here’s my workaround.
Please don’t use layout regions. This will bite you, I guarantee it.
If you’re just wanting to put returns in the text stream, Notes won’t interpret just a \n. However, there are other ways to do it. I’m not familiar enough with Java string classes, but ASCII codes 10 and 13 will be properly recognized by the client.
Subject: RE: ON NO!!!.. re: Thanks for all the responses… here’s my workaround.
My layout region happens to be in a dialogbox. I’m pretty certain this is a standard practice. Can you be a little more specific?
\r and \n essentially return 10 and 13. Notes is storing @Newline as C++ null terminators ‘\0’ which I can’t pass in. I’ve tried the Unicode = of ASCII 10 and 13 and it won’t compile. For some reason you can’t use the Unicode hex for ISO control charaters like line feed and carriage return. That’s what \n and \r are for. I just wish they’d work in Notes.
Subject: RE: ON NO!!!.. re: Thanks for all the responses… here’s my workaround.
[My layout region happens to be in a dialogbox. I’m pretty certain this is
a standard practice. Can you be a little more specific?]
Layout regions are essentially deprecated. Yes, they’re still occassionally
used in dialogs, but this practice has been avoided since R5.
[That’s what \n and \r are for. I just wish they’d work in Notes. ]
What do you see in the document properties when you use \n and \r? Does Notes
record the actual characters as literally “\n” and “\r”?
What would probably be a more reliable way to handle this would be to take the
text of the existing field, create a new richTextItem, put the text in there,
use the appendNewLine method, add your additional text, then get the
formattedText of the RTItem back out and write it to your text field.
Either that or do an evaluate(“@NewLine”). You might have some success with
that.
But layout regions… stay away from layout regions.
First off… are you suggesting using Layers? I don’t know what else could replace layout regions. I’m modifying an existing DB that is managed by another developer, so I don’t have direct control over the methods used. Do you know of an article we can read up on?
Back to the code, I tried out evaluating @Newline. The result is actually nothing (“”) when Java stores it as a string. No character, no anything.
Vector nl = session.evaluate(“@Newline”);
nl.firstElement.toString();
I had already attempted getFormattedText from a RichTextItem thanks to Simon’s messages. Java once again interprets addNewLine as \r and \n and passes them back to Notes.
To answer your question, Notes stores these escape sequences acurately. Using NotesPeek you’ll see “Line 1 Text\nLine 2 Text” in the field. Looking at the form you’ll only see “Line 1 TextLine 2 Text”. When the dialog box is opened this string is displayed as
"Line 1 Text
Line 2 Text"
Now say I manually add a new entry (pressing the Enter key) to this field using the form field. The result as seen by NotesPeek is:
“Line 1 Text\nLine 2 Text\0Line 3 Text”
The form field will show:
"Line 1 TextLine 2 Text
Line 3 Text"
The dialogbox shows:
"Line 1 Text
Line 2 Text
Line 3 Text"
The grand finale comes when I manually separate Line 1 and Line 2 (with the Enter key) in the form field.
NotesPeek:
"Line 1 Text\n\0Line 2 Text\0Line 3 Text
Form Field:
"Line 1 Text
Line 2 Text
Line 3 Text"
Dialogbox:
"Line 1 Text
Line 2 Text
Line 3 Text"
The dialogbox recognizes both \n and \0 as newlines. Freaking crazy. I hope that answers your question. The document properties displays the same thing as the dialog box.
[I don’t know what else could replace layout regions.]
Uhh… tables?
What the form shows doesn’t matter to me. The NotesPeek results are
interesting, but the real concern is what the document properties show. You’re
saying that you see the text with returns in it? That is very strange indeed
that it doesn’t show with normal text field settings.
Have you tried displaying a normal text field on the form, but set to Native OS
Style? It’s essentially the same thing you’re doing with the layout region,
but then you don’t have to use a layout.
[]Uhh… tables?[]
Heh heh… yeah, ok. We use a lot of tables. It disturbs me when hidewhen
formulas randomly disappear. Anyway…
Setting the field to Native OS worked. All returns are rendered correctly.
Notes, in fact, translates both ‘\r\n’ and ‘\n’ to ‘\0’ upon saving the
document.
More about Notes style fields… I was playing around and noticed that when I
copied text that had a ‘\n’ or ‘\r\n’ embedded that they were included in the
clipboard. I went back to the field and arrowed through the individual
characters:
Take the string “A\n\r\nB” (thus two newlines), displayed as “AB”. Notes
recognizes the placement of the returns and makes me arrow 5 times (3 escape
sequences) to get through the whole string. So it may seem like your keyboard
is acting up when you have to hit the arrow key four times just to get to B.
Thanks for your suggestions. We’ll definitely keep an eye out for this little
feature in the future. Makes integration with different platforms a little
more challenging.
Conclusion… it appears that the Text Editing engine used by Notes to display
the document properties box, text fields in a layout region, and Native OS
style fields is different from the ‘Notes style’ field engine, and that some
form of translation is required until Notes sorts it all out (assuming it ever
does).
[We use a lot of tables. It disturbs me when hidewhen formulas randomly
disappear.]
No argument from me. But here’s the difference: Lotus knows about the issues
with hide-whens & paragraph settings and is actively improving the situations
with tables. They’re not actively improving layout regions.
I mean, what are you going to do if you ever want to port your app to the web?
Seriously, they’re slower, cumbersome and tacitly deprecated. You can’t even
copy them to the clipboard effectively!
Tables have they’re own problems, true. But they’re much better than layouts
at this point.
Point taken. Now that you’ve made me think about it. A lot of our newer apps
use tables and the fitToTable param. I guess it’s just easier for me to add a
row than worry about lining everything up. But like I noted, the app I’m
working in isn’t under my control. I’ve butted heads with the other developers
before about design issues, sometimes it just take time for it to sink in.
