Natürlich müssen alle Komponenten, welche sich in der
DFM befinden, auch bekannt sein,
bevor man die
DFM wieder laden will.
RegisterClass /
RegisterClasses
Normal macht Delphi das automatisch, z.B. beim Create einer Form-Klasse, indem es alle TComponent-Typen der Published-Variablen der Klasse vorher registriert
und anschließend wieder deregistriert.
UnRegisterClass /
UnRegisterModuleClasses (z.B. HInstance einer
BPL/
DLL/EXE)
PS: Drum knallt es auch, wenn alle "Variablen" eines Types aus der Klasse gelöscht wurden.
Für statische Komponente, wie z.B. Labels, welche nie geändert und somit nie direkt im Code drauf zugegriffen wird, keine Variablen. Und alles was über FindComponent geht, dafür auch nicht.
Per se wird für das Funktionieren keine Variable benötigt (TComponent-Nachfahren füllen, bei Zuweisung ihres Namens, die gleichnamige Published-Variable, in ihrem Owner ... ACHTUNG, egal welchen Typ diese Variable besitzt),
aber wenn vorher kein manuelles RegisterClass vorkam, dann muß zwangsläufig mindestens eine Variable des nötigen Typs in der Klasse existieren, oder in ihren Vorfahren.
Wir speichern so z.B. zur Laufzeit generierte dynamische Eingabeformulare und Datenanzeigefenster in der Datenbank.
PS: Es gibt von einigen Herstellern auch Property-Inspektoren und, falls man es nicht selbst machen will, auch FormDesigner, um Komponenten mit der Maus umherschieben zu können.
Ob man zum Laden das Fenster vom
DFM-Reader automatisch erstellen will,
oder eine bereits erstellte Instanz seines Basisformular (eigene FormKlasse) mit Komponenten aus dieser
DFM befüllen will,
muß man selbst entscheiden.
Um einen TForm-Nachfahen erstmal ohne
DFM zu erstellen,
TCustomForm.CreateNew
TCustomForm und TForm kann direkt mit Create erstellen werden.
Nach gleichnamigen
DFM-Ressourcen wird erst bei Nachfahren von TForm gesucht, für jeden einzelnen Vorfahren, bis dort hin.