FMX: TMemo-Bugs in 10.4.1 (Bitte für Hotfix voten)

[Harry Stahl]

10.4.1 geht ab wie eine Rakete und es macht daher echt Spaß damit zu arbeiten.

Meine Programme werde ich aber weiterhin mit Delphi 10.3.3 veröffentlichen, u.a. wegen des geänderte Verhalten beim Einfügen von Text in ein TMemo mit "InsertAfter" (führt nun zu falschen Ergebnissen (Siehe auch Beschreibung im Bild in der Anlage).

Bug 1:
Jira-Report hier: https://quality.embarcadero.com/browse/RSP-30845


Bug 2:
Wenn man gar sowas macht im Form-Create-Event:

Delphi-Quellcode:

procedure TForm33.FormCreate(Sender: TObject);
begin
  mMuster.Lines.clear;
  mMuster.lines.Add ('<AnredeKopf>' + #13#10 + '<Titel> <Vorname> <Name>' + #13#10 +
                     '<Name2>' + #13#10 + '<Zusatz>' + #13#10 +
                     '<Strasse>' + #13#10#13#10 + '<PLZ> <Ort>');
end;

dann schrottet es das TMemo und es gibt einen Riesencursor, womit man nicht arbeiten kann (siehe Screenshot in der Anlage).

Ich wäre dankbar, wenn Ihr für die Behebung dieser Bugs voten würdet, vielleicht haben wir dann Glück und es gibt einen Hotfix....

Link zu Jira: https://quality.embarcadero.com/browse/RSP-30846

[blawen]

Gevotet

[jaenicke]

Zitat von Harry Stahl:

dann schrottet es das TMemo und es gibt einen Riesencursor, womit man nicht arbeiten kann (siehe Screenshot in der Anlage).

Einen Text mit Zeilenumbruch per Lines.Add einfügen ist auch nicht die feine Art. Man könnte das also auch vorher als Bug ansehen.
Wenn du die Zeilen als solche einfügst oder per Text zuweist, gibt es das Problem auch nicht.

Der große Cursor kommt daher, dass das ganze auch wirklich als eine Zeile angesehen wird und lediglich umgebrochen angezeigt wird.

Zitat von Harry Stahl:

Bug 1:
Jira-Report hier: https://quality.embarcadero.com/browse/RSP-30845

Nicht nur das:
Wenn du den Fokus einmal auf Memo1 setzt, siehst du, dass die zwei Zeichen des Zeilenumbruches der Cursorposition hinzugefügt werden, so dass der Cursor dann nicht nach dem eingefügten Text steht, sondern zwei Zeichen weiter rechts...

Die Ursache dafür ist, dass man die Behandlung des Zeilenumbruches vorher offenbar wirklich als Bug angesehen hat. Denn nun wird der Text zeilenweise eingefügt. Da man aber bis zur Zeilenanzahl der Einfüge-Stringlist einfügt, fällt der Zeilenumbruch am Ende unter den Tisch. Danach wird aber der Cursor um die Länge des einzufügenden Texts nach vorne gesetzt.

Delphi-Quellcode:

    Lines[APosition.Line] := Lines[APosition.Line].Insert(StartPos, AFragment[0]);
    for I := 1 to AFragment.Count - 1 do
      Lines.Insert(APosition.Line + I, AFragment[I])

[philipp.hofmann]

a) Ich würde auch empfehlen die Lines einzeln hinzuzufügen
b) Ich würde #13#10 nicht mehr benutzen, da gab es z.B. zwischen Delphi 10.3 und 10.4 ein geändertes Verhalten je nach Betriebssystem und daher sollte man besser sLineBreak nutzen (ich mache es aus historischen Gründen der Unwissenheit mit einer einfachen statischen Methode), sonst riskiert man Anzeigefehler, sobald man sich doch mal von Windows weg bewegt.

[jaenicke]

Nichtsdestotrotz ist das Problem beim Einfügen ein valider Bug. Da wurde bei Embarcadero ja auch versucht es korrekt zu behandeln, aber eine Zeile mit Zeilenumbruch am Ende wurde dabei schlicht vergessen.

[braunbaer]

beide gevoted

[Harry Stahl]

Danke für die Votings.

Hier noch eine weitere Info zu einem Problem unter Delphi 10.4.(1) und FMXLinux (alle dynamisch erzeugten Controls haben als TabOrder den Wert -1, daher funktioniert in Formularen, wo die Komponenten dynamisch erzeugt worden sind, das Tabstop nicht nicht mehr):

https://bitbucket.org/crossvcl/fmxli...ed-controls-eg

Ich werde gleich auch noch eine extra Mail an Eugen schreiben und ihn bitten, dass er das möglichst schnell fixt...

[Harry Stahl]

Zitat von philipp.hofmann:

a) Ich würde auch empfehlen die Lines einzeln hinzuzufügen
b) Ich würde #13#10 nicht mehr benutzen, da gab es z.B. zwischen Delphi 10.3 und 10.4 ein geändertes Verhalten je nach Betriebssystem und daher sollte man besser sLineBreak nutzen (ich mache es aus historischen Gründen der Unwissenheit mit einer einfachen statischen Methode), sonst riskiert man Anzeigefehler, sobald man sich doch mal von Windows weg bewegt.

Klar, #13#10 steht da nur (noch), weil ich gerade dabei bin eine ältere reine Windows-Anwendung nach FMX zu konvertieren. Da muss man natürlich sLinebreak nehmen, da das Zeilenende unter MacOS und Linux anders ist, als unter Windows (der Titel meiner Fehlerbeschreibung lautet ja auch "Adding text to TMemo with sLinebreak-signs crashed the Memo").

Aber das Einfügen von Text mit sLineBreaks muss die TMemo-Komponente schon können (wenn es über die Zwischenablage kommt, dann geht es ja auch und muss auch gehen)... Das ist einfach praktisch, das so, anstatt mit unzähligen lines.add zu machen...

[Harry Stahl]

Zitat von jaenicke:

Die Ursache dafür ist...

Danke für Deine Nachforschungen. Jedenfalls sind solche Änderungen, die bei gleichem Source-Code zu anderen Ergebnissen führen, recht problematisch.

Ich bin nur froh, dass ich das entdeckt habe und nicht meine Kunden, denn die hätten dafür bestimmt weniger Verständnis, wenn die bei Ihnen generierten Daten plötzlich anders aussehen...
(Jännicke, wann schläfst Du eigentlich, der Jira-Ticker mit Deinen Text-Änderungen klingelte die ganze Nacht durch... ))

[Harry Stahl]

Zitat von Harry Stahl:

Danke für die Votings.

Hier noch eine weitere Info zu einem Problem unter Delphi 10.4.(1) und FMXLinux (alle dynamisch erzeugten Controls haben als TabOrder den Wert -1, daher funktioniert in Formularen, wo die Komponenten dynamisch erzeugt worden sind, das Tabstop nicht nicht mehr):

https://bitbucket.org/crossvcl/fmxli...ed-controls-eg

Ich werde gleich auch noch eine extra Mail an Eugen schreiben und ihn bitten, dass er das möglichst schnell fixt...

Hierzu noch kurz die Info, dass KSDEV nun eine Version 1.47 veröffentlicht hat, die Delphi 10.4.1 unterstützt. Wenn Ihr allerdings noch Delphi 10.4. benutzt, dann bitte nicht auf FMXLinux 1.47 aktualisieren. Denn Eugene sagt - wenn ich ihn richtig verstanden habe - es sei doch ein Delphi FMX Problem und derzeit nur zu lösen, wenn FMXLinux 1.47 mit Delphi 10.4.1 erzeugt wird. Insofern würde wohl FMXLinux 1.47 nicht mit Delphi 10.4 funktionieren.

Aber super schnelle Reaktion von KSDEV, wenn von EMBA jetzt noch ein Hotfix zum Memo kommen würde, könnte ich 10.4.1 endlich für veröffentlichte Versionen meiner Programme nutzen...