@NewLine in Evaluate

[smoki]

Hallo zusammen!

Ich habe gerade ein Problem mit dem "Evaluate" einer Formel in Java.

Das folgende Beispiel macht keinen Umbruch im Zieltextfeld oder wird zumindest im Client nicht als Umbruch dargestellt:

formula="nl:=@NewLine;\"FistLine\"+nl+\"Second Line\"   ";
try {
     ret = s.evaluate(formula,doc);
} catch (NotesException e) {
     logger.error("Failed to evalute!",e);
}

Im Intenet habe ich keine Lösung hierzu gefunden, nur verschiedene Hinweise, dass es wohl generell Probleme gibt. Ein Lösungsansatz ohne Formel ist wohl: http://www.leyrer.priv.at/martin/Wissen_ist_Macht/Notes+Domino/200503_Newline_in_Java_Agents.html

Ich habe allerdings eine "komplexe Formel" die ich gerne nicht extra in Java neu schreiben möchte.

Hat jemand eine Lösung?!

Vielen Dank

Gruss
Chris

[smoki]

Da ich weiter vorankommen wollte, hab ich m³ Variante gestestet.
Entweder ich mache etwas falsch, denn ich bekomme generell eine Textliste oder es war nur "glück", dass dieses Feld in seinen Dokument, jeden Listeneintrag als neue Zeile darstellte.

Definitiv kann ich leider nicht mit einer Textliste arbeiten :/

Gruss
Chris

[smoki]

Das ist doch (sch......), selbst das entfernt den Zeilenumbruch:

Vector value = doc.getItemValue("test");
doc.replaceItemValue("test2",value);

Und alle Zeilenumbrüche aus "test" sind in "test2" konsequent... weg!! Das kann doch nicht war sein? Dann ist ja das ganze Java schrott!!

Gruss
Chris

[smoki]

Also eine Lösung habe ich für mein Problem jetzt... aber nicht toll!

Ich verwendete "@SetField" im Evaluate um den String inkl. Zeilenumbrüche zu schreiben... Aber toll finde ich diese Lösung nicht!

Vielleicht weiß ja noch jemand rat

Grüssle
Chris

[flaite]

Und alle Zeilenumbrüche aus "test" sind in "test2" konsequent... weg!! Das kann doch nicht war sein? Dann ist ja das ganze Java schrott!!

... oh boy ...
Bestätigt meine Vorurteile gegen blogger. 
Irgendwie gewinn ich da den Eindruck, dass du gar nicht darüber nachdenkst was Strings eigentlich sind.

Code

Vector value = doc.getItemValue("test");
doc.replaceItemValue("test2",value);

Versuch dir mal die Feldeigenschaften von test und test2 in den Masken anzuschaeuen.
Ich vermute, dass die Trennzeichen für multivalue unterschiedlich sind.

Gruß Axel

[smoki]

Tut mir leid, wenn ich mich im Ton vergriffen habe. Ich war gestern doch schon recht frustriert.

Meine Tests wurden unter Lotus Notes R6.5.4 unter Windows XP SP2 durchgeführt.

Die Testmaske hat folgende Felder:

Source - Textfeld, Multiple Values ist deaktiviert
Destination - Textfeld, Multiple Values ist deaktiviert

Daher sind die "multivalue" Werte definitiv gleich.

Wenn in Source nun nach Destination mit Java kopiere, verschwinden die Zeilenumbrüche. In Lotus Script und Formelsprache nicht.

Ich habe zu diesem Sachverhalt eine kleine Datenbank erstellt (siehe Anhang), die das Kopieren wahlweise mit "Formel", "LotusScript" und "Java" durchführt. Hier werden die Unterschiede realtiv schnell deutlich.

Es wäre nett, wenn sich das jemand ansehen könnte. Und mir mitteilen würde, wenn ich es tatsächlich falsch mache. Mittlerweile gehe ich allerdings davon aus das es ein Bug ist.   

Grusse
Chris

[flaite]

Das hat aber nichts mit der Abbildung von Strings in Java der Sprache zu tun.
Strings sind für mich einfach Arrays aus Long-Werten, die in unterschiedlichen Encodierungsschemen (UTF-8, ISO-8859-1, ASCI) verschiedenes bedeuten.
Ich schau mir das aber mal an.

[smoki]

Vielen Dank für die Mühe!

Leider bin ich bisher noch nicht weitergekommen.

Interessant ist auch das es beim Kopieren mit "Formel" und "LotusScript" 33 Bytes lang ist (wie im Orginalfeld)!

Und beim Kopieren mit "Java" ist es 35 Bytes lang!

[flaite]

Ohne dem jetzt weiter nachzugehen, habe ich jetzt ein bischen code in den Agenten geschrieben der den zu kopierenden String ein bischen analysiert: d.h.: er gibt die nummerischen Werte der chars aus -> in der Java Debug Konsole von Notes

->

Code

Wert:1=First Line
Second Line
Third Line
Zeichen_0=70
Zeichen_1=105
Zeichen_2=114
Zeichen_3=115
Zeichen_4=116
Zeichen_5=32
Zeichen_6=76
Zeichen_7=105
Zeichen_8=110
Zeichen_9=101
Zeichen_10=13
Zeichen_11=10
Zeichen_12=83
Zeichen_13=101
Zeichen_14=99
Zeichen_15=111
Zeichen_16=110
Zeichen_17=100
Zeichen_18=32
Zeichen_19=76
Zeichen_20=105
Zeichen_21=110
Zeichen_22=101
Zeichen_23=13
Zeichen_24=10
Zeichen_25=84
Zeichen_26=104
Zeichen_27=105
Zeichen_28=114
Zeichen_29=100
Zeichen_30=32
Zeichen_31=76
Zeichen_32=105
Zeichen_33=110
Zeichen_34=101

[smoki]

Hallo & Danke!

Teilweise bin ich auch schon so weit gekommen...

Bei getItemValue scheint er die "Returns" in "13" "10" umzusetzen, was ja "/r/n" ist und das ist ja nicht verkehrt!

Intern speichert Lotus Notes, laut C-API die Zeilenumbrüche mit "/0"! (Was ja bedauerlicherweise auch das Zeichen für End of String in C ist!)

Beim replaceItemValue scheint er dann die Konvertierung von "/r/n" nach "/0" nicht mehr durchzuführen.

Wenn man einen String "Zeile1/0Zeile 2" mit replaceItemValue wird nur "Zeile1" übertragen, der rest geht verloren. (Was logisch ist, da Java über JNI dies an die nlxbe.DLL übergibt).

Daher sehe ich keinen sinnvollen Ansatz für das Problem mehr :/

Man kann halt Workarounds bauen, z. b. "<br>" nehmen und anschließend mittels @ReplaceSubstring diese durch @NewLine ersetzen oder mit @Explode/@Implode arbeiten. Aber das sind keine schöne Lösungen.

Nochmal vielen Dank für deine Mühen!

Gruss
Chris