Hallo Delphi Freunde,

ich verwende Delphi 2010 und habe nun, nach dem aktualisieren einiger VCL Komponenten folgendes Problem.

Meine bisherigen Projekte lassen sich ohne Probleme laden und auch kompelieren. Möchte ich die Anwendung nun laufen lassen kommt sofort eine Exception mit der Meldung "Eigenschaft existiert nicht" TAdvMemo.DoubleBuffered.

Im Objektinspektor ist die Eigenschaft wirklich nicht vorhanden!

Schaltet man nun von der Formularansicht auf die Textansicht, dann findet man diese Eigenschaft. Hier habe ich versucht diese zu löschen und erneut kompiliert und kann die Anwendung auch starten. Leider wird diese Zeile mit der Eigenschaft sofort wieder hinzugefügt sobald man wieder in die Formularansicht wechselt.

Wie von Geisterhand, ich weiß nicht wie ich das reparieren kann...

Ich bitte um eure Hilfe, ich kann so nicht an meinem Programm weitermachen.

Danke, Frank

Du hast nicht zufällig eine andere Version des DesignTime-Packages dieser Komponente in der IDE,
als das Runtimepackage oder der Quellcode, mit welchem das Programm kompiliert wird?


Tja, wenn sich nach dem Upgrade (Delphi oder Fremdkomponenten) etwas ändert, dann kann es nunmal knallen.

Kompilieren lassen ist keine Garantie, da die DFM nur auf eine valide Syntax geprüft wird, bzw. wenn sie als TextDFM vorliegt, dann wird sie nach binär konvertiert und als Ressource in die EXE gelinkt.
Ob die Komponenten, Property, sonstwas wirklich "gültig" sind, ist damit also nicht gesagt.

Erst zur Laufzeit knallt es dann.
Oder eben du mußt mal alle Forms im Delphi öffnen.

Der DFM-Reader im Formdesigner ist Fehlertoleranter, bzw du hast die Wahl
* ESC, bzw. Abbrechen -> die DFM wird nicht im Designer geladen und bleibt unverändert
* manchaml wird bei ungültigen Beziehungen ein Auswahldialog gezeigt, wo man eine andere Komponente wählen kann, oder ...
* und ansonsten gibt es noch "Ignorieren", wo unbekannte Property, oder Welche die im Setter knallen, werden nicht geladen und sind beim Speichern weg
* * bzw. unbekannte Komponenten oder wo es im Constructor knallt, die würden dann auch nicht geladen/weggelasse und sind beim Speichern weg
* der Rest der DFM wird aber geladen

* da man natürlich eine Versionsverwaltung nutzt, und wenn man nicht sieht was nun genau kaputt/weg ist, nach dem Speichern, sieht man das dann im DIFF



Was aber fieß ist (DDevExtension und Co. helfen), wenn sich die Signatur eines Event änderer, also Parameter und/oder deren Typen anders sind (Name der Parameter sind egal), dann sagt dir das die IDE beim Speichern nicht ... geänderte Typen von Komponenten (in der DFM anders, als in der PAS), das sagt dir Delphi beim Speichern und repariert es.

Hallo und vielen Dank für Deine Antwort.

Den von Dir beschriebenen Dialog, bei öffnen eines vorhandenen Projektes, kenne ich und vermisse ihn in dem Fall!

Das Projekt wird anstandslos geöffnet und aööes sieht in Ordnung aus, ist es abernicht.

Kann es sein das ich diese Valid Überprüfung der Eigenschaften deaktiviert habe und wenn ja, wie aktiviert man diesen Dialog wieder? Dieses Problem habe ich noch nie gehabt und bin über 15 Jahre dabei,,, das ärgert mich schon.

Kann man irgendwie herausbekommen, auf welche DCU der nun installierten Packiges nun zugegriffen wird. Nicht das die alten Sachen noch irgendwo auf der Platte rumgammeln und für die IDE noch/auch sichtbar sind?

Gruß Frank

Zitat von Schucki:

Kann man irgendwie herausbekommen, auf welche DCU der nun installierten Packiges nun zugegriffen wird. Nicht das die alten Sachen noch irgendwo auf der Platte rumgammeln und für die IDE noch/auch sichtbar sind?

Mit everything kannst du Dateien sehr schnell überall auf der Festplatte finden (in wenigen Millisekunden normalerweise).

Mit dem Process Monitor kannst du, indem du im Filter Path contains und dann die gesuchten Dateinamen oder Teile davon angibst, sehen, worauf die IDE selbst zugreift, sowohl beim Starten der IDE als auch beim Kompilieren.

Ich selbst würde in solchen Fällen einfach die Konfiguration löschen und die IDE neu einrichten, habe mir aber sowohl beruflich wie auch privat entsprechende Skripte erstellt, die das automatisch machen.

DoubleBuffered wird in TWinControl als public deklariert und, soweit ich das aktuell nachsehen kann, im TAdvMemo schon seit vielen Jahren nicht published überschrieben. Ich gehe davon aus, dass das auch vorher nicht der Fall war. Aus diesem Grund taucht es im Object Inspector nicht auf und wird beim Einlesen aus der DFM auch nicht gefunden. In deine DFM kann es eigentlich nur dann gekommen sein, wenn es vorher mit einer modifizierten TAdvMemo Instanz gespeichert wurde. Dazu gehört aber eigentlich auch noch ein Eintrag für ParentDoubleBuffered.

Was nun genau bei dir schief läuft können wir mangels ausreichender Informationen und Überprüfungsmöglichkeiten nur raten.

Folgendes kannst du probieren: Lösch den Eintrag (bzw. beide) aus der DFM mit einem externen Editor (nicht mit der IDE). Öffne dann das Form in der IDE und wechsle in die Textdarstellung. Taucht es dann wieder auf, liegt es an dem in deinem System installierten TAdvMemo.

Der Compiler kann Dependency-Infos ausgeben.
https://docwiki.embarcadero.com/RADS...ncy_File_(*.d)
In der .D-Datei steht drin, was wirklich kompiliert/gelinkt wurde, alle DCPs und DCUs.
(hab grade vergessen welche Projektoption das war, aber da ich grade lese dass dies eigentlich von für C++ ist, dann vermutlich in jenem Tab)

Oder in die .MAP-Datei schauen.
https://docwiki.embarcadero.com/RADS...le_Types_Index

Unter Menü > Hilfe > Info über ... > Versionsinfo-Knopf sieht man, welche DLLs und Packages im Delphi geladen sind, und vor allem von wo.

Ich bedanke mich für alle Tips und Hinweise sowie Lösungsvorschläge!

Ich werde es durcharbeiten...

Wenn ich die DFM Datei mit einem externen Editor bearbeiten möchte, welchen könnt ihr da empfehlen?

Denn mit dem Windowseigenen sieht es so aus das irgendwelche Steuerzeichen drin sindindenZeilen, dass wird doch sicher nur schief gehen.

Gruß Frank

Hast du die DFM noch nicht im Textformat? Das sollte normaler Text sein. Das kann man irgendwo umstellen, ich glaube im Kontextmenü des Formulardesigners.

Wenn es dann eine einfache Textdatei ist, sollte es mit dem Windows Notepad genauso gehen wie z.B. mit Notepad++, das sehr gut ist.

Jupp, DFMs aus alten Delphis werden nicht automatisch auf Text umgestellt, welches inzwischen die DefaultEinstellung ist (für neu erstellte Forms).

Ansonsten lässt es sich auch manuell übersetzen, wenn es innerhalb des Designers knallt.
siehe System.Classes

zusammenfalten · markieren

Delphi-Quellcode:

{ Object conversion routines }

type
  TStreamOriginalFormat = (sofUnknown, sofBinary, sofText, sofUTF8Text);

procedure ObjectBinaryToText(const Input, Output: TStream); overload;
procedure ObjectBinaryToText(const Input, Output: TStream;
  var OriginalFormat: TStreamOriginalFormat); overload;
procedure ObjectTextToBinary(const Input, Output: TStream); overload;
procedure ObjectTextToBinary(const Input, Output: TStream;
  var OriginalFormat: TStreamOriginalFormat); overload;

procedure ObjectResourceToText(const Input, Output: TStream); overload;
procedure ObjectResourceToText(const Input, Output: TStream;
  var OriginalFormat: TStreamOriginalFormat); overload;
procedure ObjectTextToResource(const Input, Output: TStream; const Name: string = ''); overload;
procedure ObjectTextToResource(const Input, Output: TStream;
  var OriginalFormat: TStreamOriginalFormat; const Name: string = ''); overload;

function TestStreamFormat(const Stream: TStream): TStreamOriginalFormat;

TReader und TWriter sind zu grundeliegenden Datenklassen (für's binäre Format)
DFM heute als Text, aber im kompilierten Programm immernoch Binär und geladen wird am Ende auch das Binäre.

... und dann gibt es noch das convert-Utility, im bin-Verzeichnis von Delphi, welches binäre dfms in Text und Text-dfms in binäre umwandeln kann.

Achtung: Es gibt auch ein convert in Windows\system32, das FAT nach NTFS konvertiert.