[Gelöst] Per Script bearbeitetes RichtextItem enthält unerwartete PageBreaks

[Tode]

Wahrscheinlich gibt es für diese Anfrage keine Antwort ausser "Check Deinen Quellcode"... Ich versuchs trotzdem mal:

Ich habe hier eine App, die Serienmailings verschickt. Das Ganze ist sehr generisch, hat sehr viele Funktionen, und die "Basis- Funktionalität" kam ursprünglich mal von einem Kollegen.

Wir reden hier über ca. 5.000 Zeilen Code, verteilt auf verschiedene Script- Libraries mit vielen Klassen / Vererbung / etc...

Jetzt hat ein Empfänger dieser Mail gemerkt, dass die Mail einen Seitenumbruch / Pagebreak bei jedem Zeilenumbruch hat, was das ausdrucken unmöglich macht...

Natürlich habe ich den Code kurz überflogen, aber ein "addPageBreak" gibt es in der ganzen Datenbank nicht.

Deshalb meine Frage: Kennt jemand das Phänomen, dass in einem RichtextItem nach der Verarbeitung durch Script alle LineBreaks zu Pagebreaks werden?

Ich habe schon Codestellen im Verdacht (da wird u.U. RichtextItemRange.FindAndReplace verwendet), wollte aber wissen, ob jemand einen Script- befehl kennt, der sowas verursachen kann...

Ich werde mich natürlich parallel ans debuggen machen, aber vielleicht kann mich ja jemand in die richtige Richtung stupsen.

Danke

[m3]

Schickt das Teil HTML Mails?
Dann koennte es auch ein CSS Statement sein.

[Tode]

Nein, ist alles reines Richtext- Handling...

[Tode]

Neue (seltsame Erkenntnisse): Die Zeilenumbrüche sind nicht da, wenn die Mail generell auf eine Seite passt...
Sobald die Mail eine gewisse Länge überschreitet, wird für jede Zeile, die ich an den Text anhänge, am Anfang des Textes ein neuer Seitenumbruch eingefügt...

Also so:

50 Zeilen Mail -> Kein Seitenumbruch
51 Zeilen Mail -> Seitenumbruch nach der ersten Zeile
52 Zeilen Mail -> Seitenumbruch nach Zeile 1 und 2
53 Zeilen Mail -> Seitenumbruch nach Zeile 1, 2 und 3

usw...

Argh...

[koehlerbv]

Reagiert der Code selbst auf die Anzahl der generierten Textzeilen, Torsten?
Vermutlich eher nicht, und dann müsste das der Client selber veranstalten. Und das wäre dann wirklich "Aaaarg!" ...

Bernhard

[Tode]

Nein, im Code ist das leider gar nicht berücksichtigt... Es wird aber noch komplizierter: Die Seitenumbrüche hängen wohl auch noch mit Veränderungen der Formatierung zusammen: In einem Plain Text kommen sie nicht vor... Mache ich eine Zeile Fett und der Text wird zu lang -> Bumm... Ist momentan sauschwer zu fassen... Muss ich wohl doch Quellcode quälen...

[Peter Klett]

Seitenumbruch kann man auch mit Chr (12) erreichen, für die Suche im Script

[Tode]

Es wird immer seltsamer... Ich habe den Code jetzt mal komplett als Ursache ausgeschlossen: Ich habe einen kleinen Agenten geschrieben, der einfach ein RenderToRTItem macht, ohne irgendwelchen Voodoo:

Code

	Dim ses As New NotesSession
	Dim db As NotesDatabase
	Dim dc As NotesDocumentCollection
	Dim doc As NotesDocument
	Dim body As NotesRichtextItem
	Dim doc2 As NotesDocument
	Dim body2 As NotesRichTextItem
	
	Set db = ses.CurrentDatabase
	Set dc = db.UnprocessedDocuments
	Set doc = dc.GetFirstDocument
	Set body = doc.GetFirstItem( "NLbody" )
	Set doc2 = New NotesDocument( db )
	Set body2 = New NotesRIchtextItem( doc2, "Body" )
	Call body2.AppendRTItem( body )
	doc2.SendTo = "TEST Developer"
	doc2.Subject = "Test"
	Call doc2.Send( False, False )

Und der Produziert genau den selben Fehler... Der gleiche Code ausgeführt auf einer Mail im Mailfile mit dem selben Inhalt (kopiert aus der Problemdatenbank) verursacht den Fehler nicht...
Sieht so aus, als wäre das RTItem "NLBody" kaputt... Und zwar in jedem Dokument, unabhängig davon, welchen Inhalt ich woher paste... Liegt also wohl im Design vergraben...

@Peter: Danke für den Hinweis, wichtig fürs nächst Mal!

[pram]

Probier mal nach "Call body2.AppendRTItem( body )" ein Compact bzw. Update.
Evtl solltest du auch zur Sicherhet eine Leerzeile nach AppendRtItem machen. Hatte hier auch mal ein Problem, wenn in "body" eine Tabelle drin ist.

Gruß
Roland

/edit

...der einfach ein RenderToRTItem macht...

wo macht der Code das? Du meinst wohl AppendRtItem

[Tode]

Ja, sorry... Habs verwechselt... Ich bin einen Schritt weiter:

Der Designer der Maske hat das RichtextItem wegen der Optik in eine Tabelle gepackt. Kopiert man den Text da rein, während das Richtextitem innerhalb der Tabelle ist, dann passiert dieser Unfug... Schiebt man das Richtextfeld aus der Tabelle raus und kopiert den selben Text da rein, dann ist das RTItem sauber.

Vor laaaanger Zeit hatte ich auch mal ein so seltsames Phänomen, wenn RichtextItems innerhalb von Tabellen sind und habe das seither immer vermieden... Scheinbar verursacht das aber auch heute noch Probleme...

Den Tipp mit der leeren Zeile und dem Compact werde ich auch mal probieren (obwohl compact und Update im original- code drin sind, nur in meinem vereinfachten Beispiel nicht...

[Tode]

So, ich vermute die endgültige Lösung: Ist ein RichtextItem innerhalb eines Table, dann werden automatisch die Text- Eigenschaften "Keep Paragraph on one Page" und "Keep Paragraph with next Paragraph" aktiviert, was zu dem seltsamen Verhalten führt.

RichtextItem raus aus der Tabelle -> Alles gut..

Tja: Manchmal sind alte Erfahrungen halt auch nach vielen Jahren und über viele Versionen hinweg gültig..

[pram]

Bei Richtextitem in Tabellen hab ich auch schon negative Erfahrungen gemacht
- Seitenumbruch funktionieren nicht wie erwartet.
- Der Punkt "Neuer Abschnitt" ist grau, wenn man keinen Text markiert hat.
- Die Felder beginnen zu "wandern" wenn im RT eine Einrückung verwendet wird. Bei jedem Speichern addiert Notes den Rand der Tabelle zur Texteinrückung dazu, so dass der Text immer weiter nach rechts rückt. den Effekt kann man unterbinden, indem man in die Tabellenzelle eine Teilmaske packt die nur das Richtext-Feld enthält (+ eine verborgene Zeile jeweils davor und dahinter)
- Ist das RT-Feld in der Teilmaske gibt es noch das Problem, dass bei HTML-MIME der Fehler "Cannot Save Bitmap to disk" das Speichern abbricht. Ist das Feld in der Maske, kann man trotzdem speichern.

Ansonsten gilt wie du schon geschrieben hast: Richtexte nach Möglchkeit aus Tabellen raus (in die Maske) -> alles gut.

Gruß
Roland