Hallo Gausi,
Das ist leider nicht die Ursache. Die Basisunit MyFrameBasic.pas/.dfm wird stets mit dem Projekt in der IDE geöffnet.
Ich habe auch versucht, bei Öffnen des Projekts nur die Basisunit zu öffnen (indem ich vor Beenden der IDE die beiden abgeleiteten Units schloss), um dann diese beiden davon abgeleiteten Units MyFrameVersion1 und MyFrameVersion2 erst nach komplettem erneuten Start der IDE von Hand zu öffnen. Das brachte aber auch nichts, denn die diversen anderen Formulare, in die diese beiden abgeleiteten Units eingefügt sind, melden dann trotzdem den Fehler "TMyFrameVersion1 nicht gefunden", und ihre Formulare werden ebenfallls nicht geöffnet. Diese Fehlermeldung ist immer gleich, egal ob die abgeleiteten Units beim Öffnen der IDE gleich mit geöffnet werden oder nicht.
Das einzige was im Moment hilft ist Auskommentieren der Klassenableitungen, so wie ich es schon in meiner Anfrage beschrieb:
- In einem Editor zunächst die Klassenableitung durch Kommentarzeichen verstecken:
Delphi-Quelltext
1: 2:
| TMyFrameVersion1 = class(TFrame) |
- dann die IDE starten => funktioniert
- dann in der IDE die Kommentarzeichen vertauschen:
Delphi-Quelltext
1: 2:
| TMyFrameVersion1 = class(TMyFrameBasic) |
Nun läuft das Programm einwandfrei. Es kann also keine unzulässige Klassenableitung sein, sondern nur irgend etwas, was direkt im Startvorgang der IDE hängen bleibt.
Das ständige Ändern ist zwar unbequem, aber geht zumindest als Notnagel um überhaupt weiterzukommen.
Hat noch jemand eine weitere Idee, was ich mal probieren könnte? Eventuell über bedingte Compilierung mit {$IFDEF} & Co., wenn es irgendwas gäbe um festzustellen, in welchem Zustand sich die IDE gerade befindet?
Am Ende müsste es ja auch nicht unbedingt eine Ableitung auf dem Weg über eine "Zwischenklasse" TMyFrameBasic sein, wenn das aus mysteriösen Gründen gar nicht geht. TMyFrameBasic hat selbst gar keine visuellen Komponenten und stellt nur gemeinsame Variable und Prozeduren für TMyFrameVersion1 und TMyFrameVersion2 zur Verfügung. Theoretisch könnte ich auch eine normale Unit "TGemeinsames" mit lauter globalen Prozeduren schreiben, die dann die entsprechenden visuellen Komponenten aus TTMyFrameVersion1=class(TFrame) bzw. TMyFrameVersion2=class(TFrame) jeweils als Parameter übergeben bekommen. Aber das empfinde ich als keine "ordentliche" objektorientierte Programmierung. Und mindestens die Variablen müssten in TMyFarmeVersion1 und TMyFrameVersion 2 privat doppelt stehen, da sie nicht mehr auf dem Vererbungswege für jede der abgeleiteten Klassen privat instanziiert würden. Ein Mischen von Klassen im Stile von MyFrameVersion1 = class(TFrame, TGemeinsam) wie bei C++ ist ja bei Delphi leider nicht möglich.