Hallo,

ich habe ein Projekt von D6 auf XE4 konvertiert und dieses druckt RTF Dateien.

Ich habe nun das Problem das mir

markieren

Code:

LastChar := SendMessage(NewRichEdit.Handle, EM_FORMATRANGE, 0, Longint(@Range));
showmessagefmt('<%d><%d>',[LastChar,NewRichEdit.GetTextLen]);

Erg XE4 : <172><178>
Erg D6 : <180><178>
Unter XE4 Zeichen unterschlägt. Bei einem Test mit einer RTF Datei gibt mir die Funktion unter D6 180 und unter XE4 172 Zeichen zurück.
Das Problem ist, dass drumherum eine Schleife läuft bis alle Zeichen gedruckt sind und dadurch eine Endlosschleife entsteht, weil das Richedit wirklich 178 Zeichen ist.

Dabei ist es auch egal ob TFormatRange chrg.cpMax auf -1 oder auf NewRichEdit.GetTextLen sitzt.

Nachtrag:
Interessant ist, füge ich 3 Leerzeilen hinzu, steigt die Länge um 6, aber der Befehl oben nur um 3.
D.h ich habe nun 1 Zeile mit einem Zeichen.
Resultat 1 -1
Füge ich noch eine Zeile dazu mit einem Zeichen.
dann ist es 3-4. D.h Return wird als 2 gezählt mit GetTextLen aber nur mit einem mit SendMessage()

Nachtrag 2 Lösung
Sorry

Ich habe das Problem gefunden .getTextLen von TRichedit zählt in XE wohl wirklich 2 Zeichen für ein Return.
SendMessage(NewRichEdit.Handle, EM_GETTEXTLENGTHEX, WParam(@TextLenEx), 0); gibt die korrekte Anzahl der Zeichen zurück.

Delphi ist irgendwann dazwischen von RichEdit v1 auf RichEdit v3 umgestiegen, also bei dem gekapselten Windows-Control.

Erstmal hat sich da an den APIs bissl was geändert und intern arbeitet das RichEdit auch teilweise etwas Anderes.
In V1 werden #13#10 als Zeilenumbruch verwendet und nun halt nur noch #13 , aber Delphi pfuscht da teilweise (die haben das nie komplett umgesetzt, obwohl ich das schon vor Ewigkeiten gemeldet hatte) an den Strings rum und ersetzt beim Auslesen die #13 durch #13#10.

GetTextLen gibt also die Länge mit den "verpfuschten" #13#10 aus, aber die direkten API-Zugriffe, sowie SelStart und SelLength (das haben die Trottel vergessen), geben die Positionen/Längen/Texte mit #13 aus.

v4.1 welche oftmals auch v5 genannt wird, ist es auch schon wieder viele Jahre alt, aber da ist Delphi zum Glück sehr langsam, mit dem Upgrade.
https://msdn.microsoft.com/en-us/lib.../bb787873.aspx

d.h das ganze war bekannt. Super.

Ich hoffe ich hab nicht noch mehr Tretminen im Quellcode.
Der Code ist die GMPrintsuite welche wir nutzen. Da wird relativ viel mit RTF handtiert. IMO teilweise viel zu kompliziert.

"Bekannt" ja, auch wenn Codegear/Embarcadero das nie igendwo offiziell erwähnt hat.

Ich war damals drüber gestoplert, als irgendjemand Text färben wollte ... mit Pos in RichEdit.Text was gesucht und sich dann gewundert, warum SelStart/SelLength das verfehlen.
Nach jedem Zeilenwechsel um jeweils nochmal ein Zeichen mehr nach rechts, wie mir dann auffiel.
* einfache Lösung: raus mit dem Dreck, also dem Rumpfuschen am Zeilenwechsel
* schrierigere Lösung: die Indize umrechnen (und das hatte ich sogar schon fertig gebaut und denen gegeben)

Welche Lösung gibt es denn dann wenn das nicht gefixt wird? Ich wollte auch demnächst das TRichEdit benutzen um diverse Texte färben zu können. Auf Fremdkomponenten wollte ich nicht unbedingt zurückgreifen.

Ich hatte mir vor Monaten/Jahren mal einen kleinen Texteditor geschrieben in dem ich so etwas mit den Standard Controls getestet hatte. Da ist mir allerdings nichts aufgefallen. Vielleicht habe ich da aber nur die genannten Funktionen genutzt.

Wobei: Ich hatte auch Text markiert und dann mit einer Farbpalette eine neue Farbe zugewiesen. Das hat meines Wissens nach funktioniert.

Selber per WinAPI auf das Richedit zugreifen und nicht über die Property/Methoden des TRichEdit

oder selber umrechnen.
Im Prinzip mußt du nur die Zeilen/Zeilenumbrüche vor der Position im Richedit zählen und dann diese Zahl nochmal auf die Position draufrechnen.


ZähleZeilenmbrüche(Start bis SelStart-1) = Offset für SelStart
ZähleZeilenmbrüche(SelStart bis SelStart+SelLength) = Offset für SelLength
Das ist für Position im im RichEdit auf Position Delphi-Text umrechnen.

Nur Andersrum ist es schwerer, also für Position Delphi-Text auf Position im im RichEdit umrechnen.
Da man dort vorausschauen rechnen muß. Wenn der berechnete Offset weitere Zeilenumbrüche trifft, muß man die ebenfalls wieder mit einberechnen usw.