Problem mit SelStart

[p80286]

Frage von den billigen Rängen:

Was steht denn in SelText?
Das die Markierungen manchmal etwas eigenwillig sind ignoriere ich schon länger.

Gruß
K-H

[himitsu]

Zitat von himitsu:

[edit]
SelStart und SelLengt arbeiten wirklich nur mit einem Byte als Zeilenumbruch
Das Memo arbeitet aber noch richtig

Der Inhalt von SelText stimmt mit der Markierung überein und es enthält für einen Zeilenumbruch nur #$D.

Kann das mal bitte jemand in einer anderen unicodefähigen Sprache ausprobieren?
(nicht unbedingt C#, das wurde ja zum Teil von Delphi inspiriert)


Es ist also eindeutig im Unicode-Richedit ein anderer Zeilenumbruch, aber ob es nun an Windows oder der VCL liegt, das ist jetzt die Frage.



[edit]
es ist leider ein Problem der VCL

das Richedit scheint intern nur mit #13 (#$D) zu arbeiten,
dieses wird an vielen Stellen auch angepaßt,
aber leider nicht bei SelStart und SelLength.

z.B. in TRichEditStrings.Insert und AdjustLineBreaks sieht man eine Umwandlung zwischen #13#10 und #13.

[Hazebukelar]

Guten Morgen,

vielen Dank für Euren Input, ist ja nicht wirklich erfreulich.
It's a bug or it's a feature?

Dokumentiert scheint diese Änderung (wenn's denn eine ist?) nirgends, zumindest habe ich nichts gefunden.

Hat vielleicht noch jemand eine Idee wie wir nun damit umzugehen haben?

Die ganzen Suchroutinen welche SelStart benutzen umbauen damit es evtl. beim nächsten
Servicepack wieder geändert wurde ist auch nicht die beste Möglichkeit?

[himitsu]

Eine Möglichkeit wäre alle #13#10<>#13-Umwandlungen beim RichEdit auszubauen/abzuschalten.

Aber dann gibt es ein Problem, daß eventuell andere Dinge nicht mehr richtig arbeiten
(#13 ist außerdem kein richtiger Zeilenumbruch, das sind ja normalerweise nur #13#10 für Windows und #10 für Linux ... die #13 alleine wird von manchen Codes auch nicht richtig erkannt)



Die andere Möglichkeit wäre, bei SelStart/SelLength/SelText auch noch diese Umwandlung mit einzubauen,
damit es wieder zusammenpaßt.
Aber das hat noch nicht so richtig geklappt.
Hier mein Versuch

[Hazebukelar]

Vieleicht wäre ja auch ein Ansatz nur in der Suchroutine alle #10 aus dem Buffer zu entfernen in welchen
ich den Memotext übernehme?

Dann würden diese automatisch nicht mitgezählt werden und der Rückgabewert der Position des gefundenen
Searchstrings müsste passen und das TRichEdit müsste nicht manipuliert werden.

Meine Suchroutine wird so initialisert:

Delphi-Quellcode:

function SearchMemo(Memo: TCustomEdit;
                    const SearchString: String;
                    Options: TFindOptions): Boolean;
var
  Buffer, P: PChar;
  Size,X,Z: Integer;
begin
  Result := False;
  if (Length(SearchString) = 0) then Exit;
  Size:=Memo.GetTextLen;
  Inc(Size);
  if (Size=0) then Exit;
  Buffer:=StrAlloc(Size);
  try
    Memo.GetTextBuf(Buffer,Size);  ---> // Hier müsste man irgendwie die #10 rausschmeissen -> weißt Du dafür eine gute Lösung?
    P:=SearchBuf(Buffer, Size, Memo.SelStart, Memo.SelLength, SearchString, Options);
    if P <> nil then
    begin
      Memo.SetFocus;
      Memo.SelStart:=P-Buffer;    ---> // dann würde dieser Wert stimmen 
      Memo.SelLength:=Length(SearchString);
      Memo.Repaint;
      Result:=True;
    end;
  finally
    StrDispose(Buffer);
  end;
end;

Bekomme ich die #10 irgendwie aus dem Buffer oder gar nicht erst rein (oder sitze ich auf dem Schlauch)?

Danke.

[himitsu]

Kann mal bitte wer prürfen, ob dieses Problem(chen) in Delphi XE immernoch besteht?

> 'nen TRichEdit auf eine Form pappen
> und dann Folgendes ins OnCreate rein

Delphi-Quellcode:

RichEdit1.Text := '123'#10'456'#10'789'#10'abc';
RichEdit1.SelStart := 6;
RichEdit1.SelLength := 4;
ShowMessage(Format('%d %d', [Length(Trim(RichEdit1.Text)),
  Length(Trim(RichEdit1.Lines.Text))]));

Ist dort die "6" bis "8" markiert und die Message zeigt "18 18" an, dann wurde es wohl nicht behoben.

[Hogla]

Hallo,
habe eben dein Beitrag entdeckt.
Habe gerade das selbe Problem.
Hast du damals raus gefunden woran das liegt.

[himitsu]

Erstmal nutzt das RichEdit im Windows (nicht die alte/erste Version/API) ein #13 als Zeilenumbruch.

Jemandem von den Delphi-Entwicklern gefiel das nicht und daher wird beim Zugriff auf .Text und .Lines der Zeilenumbruch auf sLineBreak (#13#10) geändert. (was per se eine eigentlich gute Idee "wäre")
Allerdings wird hier SelText und auch SelStart+SelLength nicht ebenfalls entsprechend umgerechnet, womit diese noch auf den Indize mit #13 bassieren und es somit mit jeder Zeile um jeweils ein weiteres Zeichen verrutscht.


Ich hatte mal mühevoll versucht auch diese Indize umzurechnen und einen Bugfix für die Komponente an Embarcadero übergeben, aber na ja .... nach all den Jahren des Ignorierens wird das wohl nix mehr.

Du kannst aber ReplaceStr(RichEdit.Text, sLineBreak, #10) und ReplaceStr(RichEdit.SelText, #13, #10) nutzen (da sich das kranke Verhalten nicht abschalten lässt),
um die Texte wieder auf #13, ähhh besser #10 zurückzuändern, was dann mit den Indize von SelStart, SelText, FindText usw. übereinstimmt.


Wobei, wenn ich jetzt nochmal drüber nachdenk, dann wäre die einfachste Lösung, wenn emba das Ersetzen von #13 nach #13#10 zu #10 abändert. (auch ein richtiger Zeilenumbruch, aber genauso lang)