IDE plötzlich alles voller Fehler

[Guido Eisenbeis]

Hallo.

Delphi community edition.

Die IDE wird plötzlich mit Fehlern überflutet (siehe Screenshot). Die Ausführung funktioniert und zeigt 0 Fehler. Woher kommt das, und wie behebe ich das?

Infos:

Win 10 Pro x64. In der IDE habe ich GExperts und MessagViewHelper. Die Historie habe ich ausgeschaltet. Die Version vorher zeigt das Problem nicht. Geändert habe ich die Anordnung von mehreren Funnktionen. Die habe ich umsortiert und nach Programmablauf angeordnet. Was kann die Fehlerüberflutung verursachen?

[hoika]

Hallo,
die IDE mal neu gestartet?

Aus dem SVN die letzte Revision ausgecheckt?

[Guido Eisenbeis]

Zitat:

Zitat von hoika (Beitrag 1454142)

Hallo,
die IDE mal neu gestartet?

Aus dem SVN die letzte Revision ausgecheckt?

IDE schon einige Male neu gestartet. SVN: Ich denke, dass ich kein SVN habe, oder?

[Guido Eisenbeis]

Unglaublichen Verursacher gefunden!

Der Pfad ist scheinbar dran schuld. Pfadlänge der dproj: 193 Zeichen. Wenn ich mir den tiefsten Pfad ansehe und darin die Datei mit dem längsten Namen ("\Win32\Release\...dcu") kommt das auf 210 Zeichen. Der Pfad enthät 2 Umlaute, ob das noch was ausmacht, weiß ich nicht.

Es ist NICHT die Pfadlänge!

[Guido Eisenbeis]

Vielleicht leide ich unter "Easter Egg"-eritis!?

Was ich nun heraus gefunden habe: Die Fehlerüberflutung taucht auf, wenn der Dateipfad eine Zahl gefolgt von einem Leerzeichen, einem Minus und einem Buchstaben enthält. Beispiel:

"D:\1 -a\MyProject.dproj"

Könnte das bitte mal jemand testen?

[hhcm]

In vielen Fällen reicht es, das Projekt einmal neu zu erzeugen. (Nicht Kompilieren sondern erzeugen)

[Guido Eisenbeis]

Hallo Chris.

Zitat:

Zitat von hhcm (Beitrag 1454150)

In vielen Fällen reicht es, das Projekt einmal neu zu erzeugen. (Nicht Kompilieren sondern erzeugen)

Leider ändert sich da nichts. Ich habe neu erzeugt, dann neu kompiliert und neu erzeugt ... immer mit 0 Fehlern. Aber im Struktur-Fenster bleiben die Fehlermeldungen. Dennoch danke für den Tipp! :)

Wärst du so nett, und würdest das mit dem Pfad testen? Einfach ein leeres VLC VCL Projekt erstellen, vielleicht noch einen Button drauf und das Ganze in einen Pfad speichern wir beschrieben, z. B.

"D:\1 -a\MyProject.dproj"

Dann die IDE öffnen und auf Codeansicht schalten.

[zeras]

Zitat:

Zitat von Guido Eisenbeis (Beitrag 1454152)

Wärst du so nett, und würdest das mit dem Pfad testen? Einfach ein leeres VLC Projekt erstellen, vielleicht noch einen Button drauf und das Ganze in einen Pfad speichern wir beschrieben, z. B.

"D:\1 -a\MyProject.dproj"

Dann die IDE öffnen und auf Codeansicht schalten.

Habe ich gemacht. Einen Button auf ein leeres VCL, dann gespeichert und wieder geöffnet. Es läßt sich compilieren, aber die ganzes "uses" werden rot unterstrichen.

[Guido Eisenbeis]

Wow! Dann ist das wohl tatsächlich ein Easter Egg, oder ein übler Bug!

Vielen Dank fürs Testen! :thumb:

[Guido Eisenbeis]

Hallo zeras, ich hab nicht drauf geachtet und gedacht, die Antwort wäre von hhcm. Jetzt habe ich gesehen, dass sie von dir war. Somit gebührt dir der Dank! :wink:

[Neutral General]

Die "Fehlermarkierung" hat seit ich mit Delphi angefangen hab (vor ungefähr 15 Jahren) noch nie funktioniert und hat schon immer eine lange Liste von erfundenen "Fehlern" angezeigt.
Bis darauf die IDE (noch) langsamer zu machen hat das Feature keinen Nutzen (weswegen das das Erste ist was ich nach einer Installation ausschalte).

[Guido Eisenbeis]

Hallo Michael.

Zitat:

Zitat von Neutral General (Beitrag 1454157)

Die "Fehlermarkierung" hat seit ich mit Delphi angefangen hab (vor ungefähr 15 Jahren) noch nie funktioniert und hat schon immer eine lange Liste von erfundenen "Fehlern" angezeigt.

Dann habe ich mir doch nicht eingebildet, dass ich das schonmal hatte. (Aber diesmal werde ich mir in meine Tipps schreiben, was es verursacht!) :-D

Eigentlich finde ich die Fehlermarkierungen ganz gut. Aber nur mal für den Fall, wo findet sich denn er Ausschalter?

[Neutral General]

Tools -> Optionen

Benutzeroberfläche -> Editoroptionen -> Code Insight

[ ] Fehlermarkierung

[Uwe Raabe]

Zitat:

Zitat von Neutral General (Beitrag 1454157)

Bis darauf die IDE (noch) langsamer zu machen hat das Feature keinen Nutzen (weswegen das das Erste ist was ich nach einer Installation ausschalte).

Bedauerlich! Seit ich meine Units sauber strukturiere und zyklische Abhängigkeiten gnadenlos eliminiere, habe ich solche Fehler eigentlich gar nicht mehr. Ob die IDE dabei nun gefühlt schneller oder langsamer ist, sei mal dahingestellt. Das Coden geht damit auf jeden Fall deutlich schneller.

Ich ärgere mich immer wieder bei Fremd- bzw. Kunden-Projekten über die verlorene Zeit, wenn das eben nicht der Fall ist (in der Regel leider fast immer). Ich habe aber auch noch keinen Ansatz gefunden, diese Zeit irgendwie zu beziffern. Das wären vermutlich schlagende Argumente für ein Refactoring.

[Neutral General]

Eine deutliche Verlangsamung der IDE aufgrund dieses einen Features kann ich jetzt auch nicht nachweisen. Aber es ist eine Funktion die ausgeführt werden muss.
Und was ausgeführt wird verbraucht CPU Power.

Der Code auf der Arbeit braucht definitiv ein Refactoring - und wir sind auch dabei, aber es ist halt ein langer Prozess. Ich programmiere mittlerweile nur noch selten zu Hause an Code den ich komplett selbst geschrieben habe (ich versuche generell schon auf sauberen Code und saubere Abhängigkeiten zu achten, aber mit ner alten Codebase und vielen anderen "Köchen" ist das auf der Arbeit schwer).
Von daher kann es durchaus sein, dass die Fehlermarkierung unter den richtigen Umständen tatsächlich funktioniert.

Trotzdem frage ich mich warum die Fehlermarkierung da zumindest empfindlicher/fehleranfälliger ist, wenn Embarcadero doch den Code hat um fehlerfrei festzustellen ob die Syntax des Codes korrekt ist oder nicht. Da benutzt die Fehlermarkierung gefühlt einfach einen schlechteren Parser als der Compiler. Und das versteh ich irgendwie nicht so wirklich :gruebel:

Unterm Strich hab ichs ausgeschaltet weil ich über die Jahre mehr Falschmeldungen als wahre Fehler angezeigt bekommen habe und ich das Feature selbst wenn es funktionieren würde nicht besonders hilfreich/notwendig finde.

[Uwe Raabe]

Zitat:

Zitat von Neutral General (Beitrag 1454168)

Da benutzt die Fehlermarkierung gefühlt einfach einen schlechteren Parser als der Compiler.

Ja, das ist in der Tat so - und soll in den nächsten Versionen geändert werden. Ideal wäre nur ein Parser, der alle Teile der IDE bedient.

[TurboMagic]

Ja, es soll ein besserer und extern angebundener Parser in Zukunft benutzt werden.
Der läuft dann ja als eigener Prozess, was auch der IDE Geschwindigkeit zuträglich
sein sollte.

Wobei ich jetzt bisher nicht feststellen konnte, dass der bisherige Parser die
IDE merklich verlangsammt.

Nut: die Sache mit dem Pfad der bestimmte Zeichen kombinationen enthält sollte
bitte in QP als Bug gemeldet werden! Evtl. auch mal testen ob das generell evtl.
mit Pfaden die Leerzeichen enthalten zu tun hat?

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1454166)

Bedauerlich! Seit ich meine Units sauber strukturiere und zyklische Abhängigkeiten gnadenlos eliminiere, habe ich solche Fehler eigentlich gar nicht mehr.

Ja, das haben wir auch gemerkt. In unseren aktuellen Quelltexten mit sauberer Struktur und sauberen Dateistrukturen haben wir auch keine nennenswerten Probleme mehr mit Code Insight.

Ich hoffe, dass der neue Parser dann nächstes Jahr kommt und auch unsere älteren Quelltexte dann damit besser nutzbar sind.
Trotzdem ist die Fehlerquote von Code Insight auch ein Gradmesser für die Sauberkeit des Codes, wenn auch nicht zu 100% genau...

Ich nutze Code Insight aber auch in XE6, wo noch deutlich mehr falsche Fehlermarkierungen angezeigt wurden, weil man nach einer Weile meist recht gut ohne groß nachzudenken weiß welche Fehler falsch sind und welche wirklich welche sind.

[Redeemer]

Na ja, das Ding heißt zwar ErrorInsight, wird aber aus gutem Grund ErrorInside genannt.

In D2010 kriegt man das ganz einfach dazu, die Grätsche zu machen: Sobald du in deinem Projekt einen Record-Helper hast, ist der gesamte Quelltext rot. Keine Ahnung, bis zu welcher Version das so ist. Ebenfalls hasst es Generics und insbesondere deren Erben.

Die Deinstallation von Delphi 10.2 hat allerdings auch ErrorInside von Delphi 2010 deinstalliert. Dann war erstmal erzwungenermaßen Ruhe.

[jaenicke]

Zitat:

Zitat von Redeemer (Beitrag 1454206)

Ebenfalls hasst es Generics und insbesondere deren Erben.

Das ist schon lange vorbei. Selbst bei XE war das normalerweise kein Problem mehr. Und mit 10.2 geht es auch bei den meisten älteren Quelltexten von uns. Bei Kreuzreferenzen geht es halt in die Knie manchmal wie Uwe schon schrieb. Aber das ist ja ok, macht man eh nicht.

[Guido Eisenbeis]

Vielen Dank für eure Antworten! :thumb:

Zitat:

Zitat von Uwe Raabe (Beitrag 1454170)

Zitat:

Zitat von Neutral General (Beitrag 1454168)

Da benutzt die Fehlermarkierung gefühlt einfach einen schlechteren Parser als der Compiler.

Ja, das ist in der Tat so - und soll in den nächsten Versionen geändert werden. ...

Offen gesagt, da dieses Problem schon über 10 Jahre besteht, glaube ich nicht daran, dass behoben wird. :cry: Aber was solls, die Hoffnung ...

Es bleibt noch die Frage, wie ist es überhaupt möglich, dass der Pfad zum Projekt eine IDE-interne Funktion beeinflussen kann!?

[himitsu]

Wie: Es kommt immernoch vor, dass z.B. Pfade ohne " an Parameter ügergeben werden und dann bei Leerzeichen alles abraucht.

Auch gibt es mehrere Code-Parser, wovon nicht alle sämtliche Funktionen kennen, und teilweise wie auch der Backgroundcompiler mit falsche Bedingungen (DEFINE) arbeiten.
Raucht so ein Parser/Hintergrundcompiler ab oder er findet nicht alle Dateien, dann bricht die Aufbereitung der verlinkten Units (USES) ab, der Code kann nicht analysiert werden und schon denkt das Error-Insight es würde was nicht existieren und zeigt es als Fehler an.

Diese Funktion wurde zwar zwischendurch etwas verbessert, aber vorallem bei IFDEF und neueren Features (vor allem Funktionen/Variablen/Typen/Konstanten in Records) da raucht es immernoch ganz gern mal so richtig schön ab.

[Guido Eisenbeis]

Aah, :idea: so langsam steige ich da durch! :)

Zuerst dachte ich: "Der Pfad, in dem das Projekt gespeichert ist, befindet sich doch außerhalb der IDE. Wie kann er etwas innerhalb der IDE beeinflussen, wenn ich ihn doch gar nicht benutze?"

Zitat:

Zitat von himitsu (Beitrag 1454261)

... oder er findet nicht alle Dateien, dann bricht die Aufbereitung der verlinkten Units (USES) ab, der Code kann nicht analysiert werden und schon denkt das Error-Insight es würde was nicht existieren und zeigt es als Fehler an.

Jetzt ist mir klar geworden, dass der Pfad nicht von mir, sondern von der IDE selbst benutzt wird!

Vielen Dank für die Infos! :thumb:

[Guido Eisenbeis]

Also echt jetzt! Gerade passiert: :evil: Der Bug in der IDE tritt sogar auf, wenn man zwei Minus-Zeichen hintereinander im Pfad hat. ... Ich meine, das ist jetzt nichts so außergewöhnliches, sollte den Entwicklern denn sowas nicht auffallen? :gruebel:

[Luckie]

Spielt dann das ErrorInsight verrückt oder wie?

[Uwe Raabe]

Zitat:

Zitat von Guido Eisenbeis (Beitrag 1456440)

Der Bug in der IDE tritt sogar auf, wenn man zwei Minus-Zeichen hintereinander im Pfad hat. ... Ich meine, das ist jetzt nichts so außergewöhnliches, sollte den Entwicklern denn sowas nicht auffallen?

Offenbar nicht (hier übrigens auch nicht - insofern schon etwas außergewöhnlich).

Wenn du aber einen entsprechenden Bugreport schreibst, dann könnte das eventuell in einen Test-Case umgesetzt werden, der dann vor jedem Release durchlaufen wird. Bis dahin wissen die Entwickler aber vermutlich nichts von diesem Fehler, was für eine Behebung desselben ja schon fast existentiell wäre.

[jaenicke]

Zitat:

Zitat von Guido Eisenbeis (Beitrag 1456440)

Also echt jetzt! Gerade passiert: :evil: Der Bug in der IDE tritt sogar auf, wenn man zwei Minus-Zeichen hintereinander im Pfad hat. ... Ich meine, das ist jetzt nichts so außergewöhnliches, sollte den Entwicklern denn sowas nicht auffallen? :gruebel:

Wir haben nur normale Pfade wie:
Common\utils\graphics usw.
Das macht auch viel nehr Sinn als irgendwelche exotischen Sachen...

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1456447)

Wir haben nur normale Pfade wie:
Common\utils\graphics usw.
Das macht auch viel nehr Sinn als irgendwelche exotischen Sachen...

:thumb::thumb:

[Guido Eisenbeis]

Zitat:

Zitat von Uwe Raabe (Beitrag 1456445)

Zitat:

Zitat von Guido Eisenbeis (Beitrag 1456440)

Der Bug in der IDE tritt sogar auf, wenn man zwei Minus-Zeichen hintereinander im Pfad hat. ... Ich meine, das ist jetzt nichts so außergewöhnliches, sollte den Entwicklern denn sowas nicht auffallen?

Offenbar nicht (hier übrigens auch nicht - insofern schon etwas außergewöhnlich).

Wenn du aber einen entsprechenden Bugreport schreibst, ...

Scheinbar betrifft es nur einen einzigen Benutzer, der zudem auch noch exotische Pfade benutzt: Mich. Dafür braucht es keinen Bugreport. Sagen wir einfach, es ist ein Feature, und gut iss. :wink: Ich hätte nicht gedacht, dass ich in meinem Alter noch was exotischen mache. :P

[Guido Eisenbeis]

Zitat:

Zitat von Luckie (Beitrag 1456442)

Spielt dann das ErrorInsight verrückt oder wie?

Hallo Luckie, ich denke schon, weiß nur nicht genau, ob ich das richtig benenne. Es sieht aus wie in meinem Posting #1.

[Uwe Raabe]

Zitat:

Zitat von Guido Eisenbeis (Beitrag 1456462)

Scheinbar betrifft es nur einen einzigen Benutzer, der zudem auch noch exotische Pfade benutzt: Mich. Dafür braucht es keinen Bugreport.

Die Anzahl der betroffenen User ist zwar ein Kriterium für die Priorität eines Bugfixes, aber nicht für das Erstellen eines Bugreports an sich.

[Guido Eisenbeis]

Hallo Uwe, danke für die Info. :thumb:

Hmm, weiß nicht wie das rübergekommen ist, aber es ist ein ernst gemeintes Danke-schön.

[Luckie]

Jupp. Das ist das ErrorInsight. Das hat noch nie zuverlässig funktioniert. Schalt es einfach ab.

[Guido Eisenbeis]

Zitat:

Zitat von Luckie (Beitrag 1456467)

Jupp. Das ist das ErrorInsight. Das hat noch nie zuverlässig funktioniert. Schalt es einfach ab.

Das scheint mir eine gute Idee zu sein. :thumb:

[Luckie]

Richtige Männer brauchen das beim Programmieren eh nicht. :mrgreen:

[jaenicke]

Zitat:

Zitat von Luckie (Beitrag 1456467)

Jupp. Das ist das ErrorInsight. Das hat noch nie zuverlässig funktioniert. Schalt es einfach ab.

Bei uns funktioniert das wie schon mal geschrieben mit den aktuellen Delphiversionen und unseren aktuellen sauberen Quelltexten so gut wie fehlerfrei. Wenn du das jetzt auf Delphi 2006 wie in deinem Profil steht beziehst: Die IDE ist mit heutigen gar nicht mehr vergleichbar...
Nur in alten Quelltexten mit with, Kreuzverweisen und ähnlichen Dummheiten gibt es noch manchmal Probleme.

[p80286]

Zitat:

Zitat von jaenicke (Beitrag 1456447)

Wir haben nur normale Pfade wie:
Common\utils\graphics usw.
Das macht auch viel nehr Sinn als irgendwelche exotischen Sachen...

Darf ich mal zart darauf hinweisen, daß Benutzer eine etwas andere Auffassung von "normal" haben? Mir sind bei einem urdeutschen Unternehmen (mit internationalen Kontakten) jede Menge "anormale" Pfade über den Weg gelaufen. Wenn also zwei Minuszeichen in einem Pfad zulässig sind, dann sollte jede Software damit umgehen können

Gruß
K-H

[Uwe Raabe]

Benutzer in diesem Fall sind aber wir Entwickler und die Pfade sind die von den Delphi-Sourcen. Darauf sollte ein Entwickler eigentlich immer Einfluss haben.

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1456493)

Benutzer in diesem Fall sind aber wir Entwickler und die Pfade sind die von den Delphi-Sourcen. Darauf sollte ein Entwickler eigentlich immer Einfluss haben.

OK wenn Du das soweit einschränkst, ist es verständlich.

Gruß
K-H

[Guido Eisenbeis]

@jaenicke

Da deine Bemerkung nun Thema geworden ist, erlaube mir bitte die Frage, ob sie ernst gemeint war. Hältst du ein Minuszeichen im Pfad tatsächlich für exotisch? Und falls ja, was verstehst du unter exotisch? Und welche Zeichen noch?

Gruß,
Guido.