Problem mit SelStart

[Hazebukelar]

Hallo,

ich stelle fest dass sich SelStart in einem TRichedit in Delphi7 und Delphi2010 unterschiedlich verhält.
Folgender Code liefert in Delphi 2010 nicht das gewünschte Ergebis.

Delphi-Quellcode:

Memo.SetFocus;
Memo.SelStart:=50;
Memo.SelLength:=Length(SearchString); // Search String ist "di"

In 2010 wird der selektierte Text zwei Zeichen zu weit hinten markiert.
Ich habe zwei Screenshots angehängt.

Hat sich da was geändert?

[mkinzler]

Welchen Typ hat SearchString?

[himitsu]

Das Length scheint ja zu stimmen (oder hast du auch schonmal versucht es über einen Zeilenumbruch hinweg zu markieren? )

nur der Anfang (SelStart( stimmt eben nicht.

[s.h.a.r.k]

Schon mal den Text analysiert, der im RichEdit steht? Hast du vielleicht irgendwo zwei Leerzeichen zu viel oder zu wenig? Wie sieht das Ergebnis denn aus, wenn du die Zeilenumbrüche mal entfernst?

Edit: ich hasse dich, du roter Kasten...

[Hazebukelar]

SearchString ist ein Unicode und wird direkt im TFinddialog eingegeben.

Leerzeichen sind keine drin - es ist 100% derselbe Text im Richedit drin,
auch im Buffer sieht's identisch aus, also Zeilenumbrüche usw.

Wenn ich die Zeilenumbrüche rausmache kommt das gleiche Ergebnis raus, damit
könnte es was zu tun haben

Der Wert für SelStart kommt übrigens im "Echtbetrieb" aus einer Suchroutine und ist in
den unterschiedlichen Delphi Versionen identisch.

Lediglich die Markierung wird in D2010 falsch gesetzt.

Es sieht fast so aus als würden die Zeilenumbrüche #13 #10 von SelStart in D2010 anders (falsch?) gezählt.

Ich such schon den ganzen Tag...... :wall:

Wie verhält sich das denn bei Euch (unverschämte Frage)?

[s.h.a.r.k]

Hm... Ich denke eher dass es an Unicode liegt. War mein erster Gedanke, aber ich vermute das halt nur :oops: Ich wüsste nicht, woran ich das nun festmachen könnte...

Zitat:

Wenn ich die Zeilenumbrüche rausmache kommt das gleiche Ergebnis raus, damit
könnte es was zu tun haben

Lass dir viel mal Character für Character ausgeben, also in D7 und D2010. Vielleicht kommt da ja was anderes raus.

[jaenicke]

Ja, dass es an den Zeilenumbrüchen liegt, hatte ich auch schon vermutet, als ich vor zwei Tagen diese (ähnliche) Frage gelesen habe:
http://forum.delphi-treff.de/showthread.php?t=28282
(Leider kann ich es im Moment nicht testen.)

[Hazebukelar]

An Unicode habe ich auch gedacht, aber auch ich finde da absolut keinen Ansatz.

Wenn's ein Unicode Problem wäre dann wäre SelStart aus meiner Suchroutine falsch - ist aber identisch.

Die Zeichen habe ich eins zu eins verglichen - identisch.

Auch mal in ein leeres Memofeld manuell die selben Zeichen reingetippt - auch keine Änderung.

Sobald Umbrüche drin sind verschiebt sich der markierte Text immer mehr nach hinten, je mehr Umbrüche
desto größer der Versatz.

Da mangelts wirklich an Ideen...... :shock:

[s.h.a.r.k]

Nutzt du dir Methode zur Positionsbestimmung, oder? Und da kommen die gleichen Wert raus? :gruebel: wenn das wirklich so ist, dann würde ich wahrlich an der TRichEdit zweifeln. Entweder, dass da ein Problem mit Unicode vorliegt, oder dass sich dadurch vielleicht intern etwas geändert hat. Total strange...

[himitsu]

Delphi-Quellcode:

RichEdit1.Text := '12345'#13#10'abcdefgh';
RichEdit1.SelStart := 9;
RichEdit1.SelLength := 3;

Dieser Code selektiert in D4, D7 und D2006 "cde"
und in D2009, sowie D2010 ist es "def".

[add]
Die Zeilenumbrüche scheinen OK:gruebel:
Hab sie grad mal via SendMessage direkt ausgelesen.


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

[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:

Zitat von himitsu

[edit]
SelStart und SelLengt arbeiten wirklich nur mit einem Byte als Zeilenumbruch :wall:
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?
:wiejetzt:

[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)? :feuerchen:

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

Delphi-Quellcode:

ReplaceStr(RichEdit.Text, sLineBreak, #10)

und

Delphi-Quellcode:

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)