Editor wird nicht richtig gezeichnet

[Codehunter]

Hallo!

Ich habe folgendes Problem: Ich habe Delphi (10.2.3) in einer VM installiert. Wenn ich per STRG-Click und/oder Vorwärts-Rückwärts-Navigation hin und her springe, dann wird der Editor nicht richtig gezeichnet. Die Zeilen werden versetzt gepinselt. Das bereinigt sich, wenn ich ein bisschen mit dem Mauswheel herum scrolle. Dennoch ist das sehr lästig. Allerdings kann ich das Problem nicht genau eingrenzen. Ich habe schon vergeblich alle IDE-Extensions deinstalliert und neu installiert. Auch ganz ohne Extensions das selbe Problem. Ich vermute, sicher bin ich da nicht, dass es was mit der VM zu tun haben könnte. VirtualBox und Intelgrafik sind einfach keine Freunde. Bisher habe ich das Problem auch nur auf diesem einen Rechner. Vielleicht kennt das ja jemand von euch auch?

Grüße
Cody

PS: Auch wenns so ähnlich klingt, es ist nicht dieses Problem. Der Textcursor steht in der richtigen Zeile, nur wird der Editor auf seinen Canvas falsch gezeichnet.

EDIT: Kleine Ergänzung noch: Das Problem tritt NICHT auf, wenn ich alle im Quelltext vorhandenen {$REGION} aufklappe. Es scheint also mit dem Codefolding zu tun zu haben.

[Sherlock]

Hab ich auch immer wieder. Insbesondere wenn ich nach größeren Änderungen den Code neu formatieren lasse. Eine weitere Formatierung richtet es dann in aller Regel wieder.

Sherlock

[Codehunter]

Bei dir auch in einer VM?

[Sherlock]

Parallels in MacOS. Also ja. Ich glaube aber, daß es eher an Zusatzprodukten wie CnPack, GXperts etc. liegt.

Sherlock1

[TigerLilly]

VMWare Tools installiert + aktuell?

[Pfaffe]

Habe VMWare Fusion 11.0.2 und die VMWare Tools 10.3.2 im Einsatz, CnPack und GXperts sind installiert und habe das Problem nicht.

[Codehunter]

Bei mir isses kein VMWare.

[Codehunter]

Update: Die Intel-basierte Grafik der Hostmaschine kann ich inzwischen als Ursache ausschließen. Ich habe die VM auf einem Ryzen/Vega11 ausprobiert, da sind die Darstellungsfehler identisch. Extensions kann ich wie gesagt inzwischen auch ausschließen, weil auch wenn komplett deinstalliert die selben Fehler auftreten. Damit scheint es wohl ein Delphi-internes Problem zu sein, das irgendwie mit dem Codefolding zusammen hängt. Dieses scheint wohl nach wie vor etwas buggy zu sein, denn neben den Darstellungsfehlern gibt es auch das oben verlinkte Navigationsproblem. Vielleicht hängen die sogar ursächlich zusammen, wer weiß.

[Uwe Raabe]

Manchmal sind fehlerhafte Zeichen oder Zeilenumbrüche in den pas-Dateien die Ursache für solche Probleme.

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1423099)

Manchmal sind fehlerhafte Zeichen oder Zeilenumbrüche in den pas-Dateien die Ursache für solche Probleme.

Ist nicht auszuschließen. Grad wenn man z.B. Strings aus PDF-Dateien kopiert, was bei uns häufiger vorkommt. Die Frage ist, wie findet man die am elegantesten? Die Units sind ja recht umfangreich.

[Uwe Raabe]

Was die Zeilenenden betrifft, hiermit:

Delphi-Quellcode:

program CleanLineFeeds;

{$APPTYPE CONSOLE}

uses
  System.SysUtils,
  System.IOUtils;

procedure HandleFile(const FileName: string);
var
  S: string;
begin
  S := TFile.ReadAllText(FileName);
  S := AdjustLineBreaks(S);
  TFile.WriteAllText(FileName, S);
end;

procedure Main;
var
  I: Integer;
begin
  for I := 1 to ParamCount do begin
    HandleFile(ParamStr(I));
  end;
end;

begin
  try
    Main;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

[TERWI]

Ich hol das mal hoch und häng mich mal an ....

Seit einigen Tagen nach ewigem Drama mit exitstierendem D2009 nun endlich die 10.3.2 drauf.

Mir fiel zeitig auf, dass das Code-Folding irgendwie an manchen Stellen und auch nicht in allen Units eben nicht so wirklich passt.
Dazu noch das wesentlich eklatantere Prob, dass nach dem kompilieren mit Fehler die Anzeige irgendwo ([viel] tiefer) steht, als der eigentliche Fehler selbst.

Hab mir nun mal die Quelltexte meines 1. Testprojektes mit NotePad++ angesehen und war entsetzt über die Vielzahl von nur LF oder nur CR oder auch LFCR statt CRLF.
Fällt ja auch sonst so nicht auf .... und D2009 hat nie darüber gemeckert.

Frage mich nur, woher das kommt ?
Ich kopiere zwar auch gelegentlich etwas von irgendwo in den Code - aber das sehe ich auch bei prozeduren die ich z.B. vor 2 Tagen erst selbst eigenhändig in 10.3.2 getippt habe !

NACHTRAG:
Der Code-Schnipsel von Uwe in #11 funktioniert 1A !

[Harry Stahl]

Oh wie gut, dass ich diesen Beitrag gelesen habe.

Denn ich hatte bei einem Projekt auch schon einige unerklärliche Probleme beim Debuggen festgestellt, wie Breakpoints an falschen Stellen gesetzt, Geisterhaltepunkte, etc.

Außerdem wurden bei neuen Ereignis-Prozeduren (etwa gesetzt durch Doppelklick auf einen TButton), diese mitten in andere Prozeduren rein gesetzt, mit dem Hinweis, dass "Name der neuen Prozedur" nicht gefunden werden konnte.

Auch funktionierte die Codevervollständigung nicht mehr..
Also auch mit Notepad++ nachgesehen und die gleiche Problemlage gefunden.

Damit man nicht alle anderen Dateien in einem Projekt per Hand überprüfen muss, habe ich eine entsprechende Funktion in meinem Pascal-Projekt-Manager (aktualisierte Version 3.17 vom heutigen Tage) auf der Basis von Uwes Lösung eingebaut. Man kann erst prüfen oder direkt beheben lassen, siehe Screenshot in der Anlage.

Jetzt funktioniert wieder alles wie es soll!

[Luckie]

Im Wort "breaks" ist im Beschreibungstext ein Tippfehler! Ich würde auch das deutsche Wort nehmen. Klingt so etwas 'komisch.

[Codehunter]

Ich hatte noch nie derartige Probleme. Mein Bauchgefühl sagt mir, dass da nicht die IDE selbst dran schuld ist. Evtl. ein Plugin oder ein externes Tool wie Git. Man kann doch die IDE konfigurieren, welche Art Linebreak verwendet werden soll. Wenn jetzt in einem verteilten Projekt der eine Entwickler mit CRLF arbeitet, der andere mit LF, noch einer mit LFCR usw. dann könnte ich mir vorstellen, dass ein Versionssystem beim Zusammenführen die Linebreaks vermasselt. Wenn so ein Fall mal vorliegt wäre es interessant die betreffende Zeile genau zu finden und dann in den Versionslogs nachzuschauen ob die mal explizit von einem Merge betroffen waren.

[Harry Stahl]

Habe das Projekt mal verglichen, als es noch ein Delphi 2007 Projekt war, da waren die Fehler schon drin. Kann sein, dass damals auch sich schon ähnliche Probleme ergeben hatten (hatte es über die Jahre (selten) mal wieder und war sehr frustriert, dass ich da nicht raus finden konnte, woran es lang).

Übrigens habe ich noch eine kleiner Änderung am PPME vorgenommen, denn Uwes Lösung hatte zur Folge, dass die korrigierte Datei immer als UTF-8-Datei geschrieben wird. Sollte normalerweise kein Problem auch für ältere IDE's sein, allerdings könnte das evtl. für andere Tools problematisch sein, die irgendwie in das Projekt eingebunden sind.

Prüfe also auf Encoding (zeige es auch in der Analyse an) und speichere die angepasste Version auch wieder als ANSI-Datei, wenn es denn Ansi war (siehe anlg. Screenshot).

Man kann die IDE meines Wissen übrigens nicht dahingehend konfigurieren, ob nur LF oder CR/LF verwendet werden soll, sondern nur, ob CR angezeigt werden sollen oder nicht.

[TERWI]

@Harry Stahl
:-D ... ich hatte mir auch so ein ähnliches Tool aus Uwe's Schnipseln gebastelt.

Ich beharre allerdings auf der Lösung der Frage:
Wieso ist da neuerdings Rio (oder auch andere davor ?!) so zimperlich mit fehlerhaftem CRLF ?
Hat doch 'früher nie gestört...'

Und noch mal die Frage:
Woher kommt das ?
Wenn man Code irgendwo her aus dem WWW, PDF oder sonstwoher kopiert, ist das sicherlich zu verstehen ...
... aber ich habe relativ schnell und offensichtlich Zeilen im NotePad++ gefunden, welche ich im neu installiertem Rio selbst getippt habe und welche da nur ein 'LF' am ende hatten oder auch ein 'CR' in der nächsten Zeile.

D.h. gehe ich davon aus, dass hier in der IDE irgendwo irgendwas 'verschlimbessert' wurde und das schnellstmöglichst geprüft / behoben werden sollte !

Würde es nur das Folding oder Block-Anzeige betreffen, wäre das ja nur eher kosmetische Nachhilfe.
... aber auch Harry Stahl hat ja festgestellt, dass diese "FalschMännchenHeintzchen" ja auch offensichtlich die Fehleranzeige/Debugguing gehörig durcheinanderbringen und den User zur Verzweiflung treiben (können).

[dummzeuch]

Der GExpert Code Formatter konvertiert übrigens ebenfalls automatisch LF in CR/LF. Vermutlich habe ich dieses Problem deshalb noch nie gesehen.

[Uwe Raabe]

Wo wir jetzt schon bei Plugins sind: Der Project Magician macht das optional beim Öffnen der Source-Datei.

Zitat:

Only as part of the global options you have access to the Clean Line Feeds feature. When opening dpr, dpk, pas or inc files any invalid line feed sequence (like single <CR> or <LF> alone) will be converted to a proper <CR><LF> sequence.

Ohne das jetzt selbst überprüft zu haben, soll das Abwählen der Option Zeilenenden erhalten in den Editor-Optionen denselben Effekt haben.

[TERWI]

... und wo genau im Dschungel der Optionen findet man eben diese ?
Tools oder Projekt ?

[Uwe Raabe]

Zitat:

Zitat von TERWI (Beitrag 1453865)

... und wo genau im Dschungel der Optionen findet man eben diese ?
Tools oder Projekt ?

Tools - Optionen - Editor-Optionen

bzw. ab Delphi 10.3

Tools - Optionen - Benutzeroberfläche - Editoroptionen

[TERWI]

.... aaaah - Danke !
ABWÄHLEN, war hier markiert.
Mal schauen was das bewirkt, wenn ich demnächst mal älteren Source lade.

Ich verstehe nur den Sinn dieser Option nicht, das - wenn man sie nicht abwählt - die IDE dann so einen "Stress" verursacht ?!

[Uwe Raabe]

Na ja, alternativ hat man dann womöglich Stress mit dem VCS.