Ok, ja. B0rken as designed. ;)
BTW - ich hab nun doch eine Lösung gefunden:
Vector fv = new Vector();
fv.addElement( "Text 1" );
fv.addElement( "Text 2" );
doc.replaceItemValue("History", fv);
Text 1
Text 2
und nicht
Text1||Text2
Warum das auch bei reinen Textfeldern und nicht nur bei Multivaluefields funktionert versteh ich zwar nicht, aber ich freu mich drüber. :)
So, und dafür hab ich mir heute ein Bier verdient. ;D
Hi Roland,
habs gerade mit '\u0000' auf Windows getestet, das Resultat ist, dass in Notes der String ab dieser Stelle abgeschnitten wird, also aus:
"Das ist ein " + '\u0000' + "Zeilenumbruch"
wird in Notes:
"Das ist ein"
..und der Rest fehlt leider :(
Sonst noch eine Idee? Ist immens wichtig, da der Kunde das ohne Zeilenumbrüche nicht akzeptiert und "geht mit Java und Notes nicht" wikrt irgendwie lächerlich :)
Danke und Grüße
Thomas
Du kannst mir zu meinem ersten selbstgeschriebenen (oder zusammenkopierten) Java-Agenten gratulieren. Das Thema hat mich ja nun doch irgendwo gejuckt. Nach ein bißchen Hilfe-Stöbern bin ich zu folgender Lösung gekommen:
import lotus.domino.*;
public class JavaAgent extends AgentBase {
public void NotesMain() {
try {
Session session = getSession();
AgentContext agentContext = session.getAgentContext();
DocumentCollection dc = agentContext.getUnprocessedDocuments();
Document doc = dc.getFirstDocument();
Stream stream = session.createStream();
stream.writeText("Zeile1", Stream.EOL_CR);
stream.writeText("", Stream.EOL_LF);
stream.writeText("Zeile2");
stream.setPosition(0);
doc.replaceItemValue("Test", stream.readText());
do {} while (!doc.save(false, false, true));
} catch(NotesException e) {
e.printStackTrace();
} catch(Exception e) {
e.printStackTrace();
}
}
}
Der tut unter 8.5.1 genau das, was er soll.
Der Trick ist bei den Stream.EOL_CR und _LF. Wenn man nur den Stream.EOL_CRLF nutzt, wird der Zeilenumbruch in der Felderliste angezeigt, aber nicht im geöffneten Dokument. Vermutlich sind da die Zeichen 13 und 10 vertauscht (laut Hilfe ist EOL_CR = ASCII 13, EOL_LF = ASCII 10 aber EOL_CRLF = ASCII 10 + 13. Korrekt wäre aber ASCII 13 + 10. Vermutlich stimmt die Doku mit der Umsetzung überein).
Durch die einzelne Verwendung von EOL_CR und _LF stimmt dann die Reihenfolge wieder.
Möglich, dass da noch ein paar Unsauberkeiten drin sind (z.B. sehe ich gerade zwei catch (Exception), da ist bestimmt einer doppelt?), aber vielleicht hilft Dir die Kernaussage weiter.
2 catch sind ok. Du kannst aber auch einfach die erste löschen.
Oder versuch die mal umzudrehen.
catch Exception vor catch NotesException. Und dann gucken, was der Compiler sagt.
In meinem aktuellen Projekt würd ich das so schreiben, aber das ist halt auch irgendwie chi chi. ;)
} catch(Exception e) { // NOSONAR catching RuntimeException is save in this context.
e.printStackTrace();
}
Was soll eigentlich diese Zeile ???
do {} while (!doc.save(false, false, true));
doc.save(false, false, true);
Ich würd den stream sicher schliessen. Müsste man auch in LotusScript machen, macht nur keiner. Falls zwischen dem Öffnen des Streams und dem schliessen ein Fehler auftritt, wird das schliessen nie erreicht. Finally wird dagegen immer aufgerufen. In Java7 gibt es ein try with ressources AutoCloseable Feature, das diese traditionelle Turnübung unnötig macht.
stream.writeText("Zeile2");
stream.setPosition(0);
stream.close();
stream = null;
} catch(Exception e) { // NOSONAR catching RuntimeException is save in this context.
e.printStackTrace();
} finally {
if (stream != null) {
try {
stream.close();
} catch (IOException ioe) {} // NOSONAR empty catch is fine to close stream in finally.
}
}
Aber einfach nicht verunsichern lassen. So wichtig ist das alles nicht. Hauptsache es tut.
This agent saves a document. The agent keeps trying if the document is not saved because someone else modified it while the program was running.
Das macht natürlich Sinn.
Aber wer schreibt in LotusScript etwas in der Art:
while doc.save(false, false, true) != false then
' do nothing
wend
In bestimmten Randfällen für spezifische Aufgaben, mag das Sinn machen. Ganz sicher nix Java spezifisches.