CE 10.4.2: IDE friert beim Laden des Hauptformulars ein.

[Maekkelrajter]

Ein Projekt, das ich bisher unter Delphi 10.3.2 und 10.3.3 (CE) entwickelt habe, zeigt unter 10.4.2 ein fatales Verhalten. Sobald ich das Hauptformular zu laden versuche, friert die IDE ein und ist nur noch per Taskmanager zu beenden. Das Projekt läßt sich fehlerlos compilieren bzw. erzeugen und aus der IDE starten. Wenn ich aber versuche, 'Mainform.pas' in die IDE zu laden, ist Feierabend. Meist friert die IDE ohne Vorwarnung ein, aber manchmal gibt es auch obskure Fehlermeldungen wie ' Eine Zeile war zu lang und musste abgeschnitten werden', oder 'Fehlerhafter Zeiger' ('Details' s. Anhang). Damit kann ich leider überhaupt nichts nichts anfangen. Hat jemand einen Tip?

Gruß LP

[hoika]

Hallo,
benutze den Windows-Editor.

- Neue Datei
- Inhalt der Pas-Datei dort rein

Schau dir die Datei mal jetzt an und suche nach "komischen" Zeilen.

Speichern und Beten.

[Maekkelrajter]

Zitat von hoika:

Hallo,
benutze den Windows-Editor.

Schau dir die Datei mal jetzt an und suche nach "komischen" Zeilen.

Speichern und Beten.

Da hilft offensichtlich auch beten nichts. Das seltsame ist ja, dass der Compiler anscheinend weder mit der pas - Datei noch mit dem Formular (.dfm) Probleme hat, nur die IDE zickt
Wenn ich die dfm-Datei umbenenne erscheint die untenstehende Meldung. Die IDE friert dann zwar nicht ein, aber die pas-Datei wird auch dann nicht geöffnet, und erwartungsgemäß meckert der Compiler.

Gruß LP

[Uwe Raabe]

Welche Nicht-Standard-Komponenten sind denn in dem Formular?

[TiGü]

Packe das Hauptformular in ein komplett leeres VCL-Projekt zum Test.

[Delphi.Narium]

pas und dfm jeweils mit Notepad öffnen und dann speichern (vorher ggfls. Kopien erstellen).

Wenn das nicht hilft: Zwei Notepad öffnen. Im ersten die pas bzw. dfm öffnen, dann per Strg+A alles markieren, per Strg+C im zweiten Notepad einfügen und speichern.

Ab und an passiert es schonmal, dass eine Datei aus unerfindlichen Gründen Zeichen enthält, mit der die IDE nicht zurechtkommt. Für den Kompiler ist's aber halt kein Problem.

Da IDE <> Kompiler kann man auch nicht einfach erwarten, dass das, was die IDE schluckt, auch zwingend vom Kompiler geschluckt werden muss, bzw. umgekehrt.

Plötzlich auftretende Fehler ala "zu lange Zeile" sind häufig Folge von ungültigen Zeichen in 'ner Datei. Da wird irgendwo ein Zeilenumbruch nicht mehr korrekt erkannt und ab da gibt es dann einfach nur noch Strubbel (weil z. B. mal aus 'nem Windowszeilenumbruch ein Unixzeilenumbruch wird ...).

Ansonsten siehe: https://www.delphipraxis.net/23885-f...3-zeichen.html

[TurboMagic]

Ähm, in 10.4.2 gibt's doch glaube ich eine Einstellung wie die IDE
die Zeilenenden behandeln soll. Evtl. kann die IDE bei passender
Einstellung das dann automatisch korrigieren?

[Maekkelrajter]

Zitat von Delphi.Narium:

Zwei Notepad öffnen. Im ersten die pas bzw. dfm öffnen, dann per Strg+A alles markieren, per Strg+C im zweiten Notepad einfügen und speichern.

Dieser Tip hat mich auf die richtige Spur gebracht. Nach dieser Aktion lief tatsächlich alles wie geschmiert. Aber mich interessierte natürlich, wo der Fehler bzw. die Unterschiede zwischen beiden Dateien liegen. Im Text waren zunächst keine Unterschiede zu erkennen. Allerdings war die 'fehlerhafte' Datei UTF-16 LE (mit BOM) codiert, die funktionierende aber in ANSI. Daraufhin habe ich mal alle Quelldateien des Projektes überprüft. Fast alle sind ANSI-Codiert, nur 2 in UTF-8 und nur das Hauptformular, der Teufel weiß warum, in UTF-16. Eigentlich sollte doch die IDE mit allen Codierungen zurechtkommen. Oder doch nicht? Also womöglich ein Bug?
Jedenfalls Danke für die Tips!

Gruß LP

[himitsu]

Wenn Delphi automatisch die Kodierung ändert (nicht ohne Rückfrage, wenn das zu Speichernde nicht reinpasst), dann zu UTF-8.

UTF-16 wählt Delphi doch garnicht von alleine.

[dummzeuch]

Zitat von Maekkelrajter:

Eigentlich sollte doch die IDE mit allen Codierungen zurechtkommen. Oder doch nicht? Also womöglich ein Bug?

Ja, sollte sie. Aber mit allem außer ANSI und UTF-8 wäre ich sehr vorsichtig. Auch externe Tools kommen nicht immer mit anderen Encodings klar.