RTF-Element in Tabelle wird nicht richtig dargestellt!

Deutschsprachiges Forum
1

Hallo!
Ich benutze L&L26 und habe in meinem Report innerhalb ein RTF-Element in einer Zeile. Nun stellt L&L jegliches RTF bei uns falsch dar. Nehme ich alleine das simple Wort “Test” ohne weitere Formatierungen (kursiv/fett) und speichere es mit WordPad entsteht das folgende RTF:

{\rtf1\ansi\ansicpg1252\deff0\nouicompat\deflang1031{\fonttbl{\f0\fnil\fcharset0 Calibri;}}
{*\generator Riched20 10.0.18362}\viewkind4\uc1
\pard\sa200\sl276\slmult1\f0\fs22\lang7 Test\par
}

Dies in der Darstellung durch L&L 26 im Report: ouicompatTest
→ es wird aus irgendeinem Grund immer “ouicompat” in die Darstellung mit eingebracht. Ich habe testweise in C# ein kleines Testprojekt geschrieben, dass den RTF-Editor von Winforms benutzt und mir hier das RTF generieren lassen:

{\rtf1\ansi\ansicpg1252\deff0\nouicompat\deflang1031{\fonttbl{\f0\fnil\fcharset0 Microsoft Sans Serif;}}
{*\generator Riched20 10.0.18362}\viewkind4\uc1
\pard\f0\fs17 Test\par
}

Erzeugt die gleiche falsche Darstellung im Report. Speichere ich das oben generierte RTF in einer .rtf-Datei wird es mir in jeglichen Textverarbeitungsprogrammen ohne Weiteres korrekt angezeigt. Bitte um eine Rückmeldung hierzu. Aufgrund dessen, dass wir große vielseitig formatierte Textpassagen in den Report einbauen wollen, möchten wir das zugehörige RTF nicht von Hand erzeugen müssen. Falls ein 100% kompatibler freier Editor bekannt ist, wäre das auch schon eine Hilfe.

2

Ich kann das hier nicht nachstellen. Bei mir wird folgendes RTF erstellt:

{\rtf1\ansi\ansicpg1252\deff0\nouicompat\deflang1031{\fonttbl{\f0\fnil\fcharset0 Calibri;}}
{\*\generator Riched20 10.0.19041}\viewkind4\uc1 
\pard\sa200\sl276\slmult1\f0\fs22\lang7 Test\par
}

Wenn ich das speichere und im Designer in einem RTF-Feld darstelle bekomme ich die korrekte Ausgabe:

image

Wie genau übergeben Sie den RTF-Inhalt in das Feld?

3

Ihr Post mit der letzten Fragestellung gab uns den entscheidenden “Tipp”. Wir liefern die RTF-Bausteine aus einer Datenbank. Bei INSERTS haben wir mit Escape-Zeichen z.B. Umlaute und Hochkommatas erfolgreich markiert. Jedoch interpretierte die Datenbank bei diesem Teilstring “deff0\nouicompat” das “\n” und entfernte beim genauen Hinsehen “\” aus der Zeichenkette. Genau wie zufälligerweise der von Ihnen auf dieser Page hier bereitgestellte Editor zum Verfassen dieses Posts :smiley: .Wir haben nun unsere Inserts dahingehend mit weiteren Escape-Zeichen korrigiert und erreichen auch die gewünschte Darstellung im Report.

Somit lag der Fehler definitiv auf unserer Seite! Ich bedanke mich sehr für Ihre schnelle Rückmeldung mit dem Hinweis, der zur Lösung verhalf!

1 Like
4

Ja, manchmal steckt der Teufel im Detail - das kennen wir alle :laughing:.