vererbtes Formular - abstrakter Fehler

[t2000]

Ich hab einen Fehler, bei dem ich noch keinen (schnellen) Ansatz für die Fehlersuche habe.
Ich stelle hier mal die Frage, ehe ich die aufwendige Methode nutze und alle Komponenten entferne und nacheinander wieder einfüge. (noch unklar, türlich)

Ich habe eine VCL-Form mit einigen Komponenten/Funktionen. Diese soll als Basis für weitere dienen.
Als "echte" Komponente liegt auf der Form nur ein TTimer.
Weiterhin einige eigene Feldvariablen und Funktionen.
Interessant vielleicht noch

Delphi-Quellcode:

    procedure AfterConstruction; override;
    procedure BeforeDestruction; override;
    function CloseQuery: Boolean; override;

aber wirklich nicht wildes drin.

Jetzt erzeuge ich ein neues Formular (vererbt von dem ersten).
Mehr nicht.

Nun das Problem.

Wenn ich den Vorgänger offen habe, kann ich das abgeleitete Formular öffnen. Kompilieren, läuft alles.
Wenn ich das Vorgängerformular NICHT offen habe, kommt beim Öffnen des abgeleiteten Formulars dieser Fehler:

"Fehler beim Erzeugen von Formular: Abstrakter Fehler."

Ich klicke "ok" und das Formular öffnet sich.

Das gleich passiert auch, wenn ich Delphi schließe und beim Neustart BEIDE Formulare offen waren. (also sie wieder automatisch geöffent werden sollen). Nur dass dann sich der ganze IDE-Editor nicht öffnet.


Kennt das jemand? Hat schom mal jemand sowas gehat und ein Tipp für mich?
Sonst muss ich wohl mit einem neuen leeren Formular neu anfangen und nach jeder kleinen Änderung neu testen. Reichlich aufwendig.

Gruß Thomas

[haentschman]

Zeig mal das Basisformular. Da fehlt imho ein "virtual"...

[t2000]

Delphi-Quellcode:

type
  TBasisView = class(TForm)
    TrackingTimer: TTimer;
    procedure TrackingTimerTimer(Sender: TObject);
  private
    FViewmodel           : TsngViewmodel;
    FTrackingTimerTime   : Cardinal;
    FOnTrackingTimer     : TNotifyEvent;
    FHandleEnterAsOk     : Boolean;
    FHandleEscAsCancel   : Boolean;

    procedure RestartTrackingTimer;
  protected
    procedure edEnter(Sender: TObject);
    procedure edExit(Sender: TObject);
    procedure edKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
    procedure edEditChange(Sender: TObject);
    procedure edCheckboxChange(Sender: TObject);
    procedure edRadioChange(Sender: TObject);
    //procedure IsDialogKey(const Key: Word; const KeyChar: WideChar; const Shift: TShiftState;var IsDialog: boolean); override;
  public
    procedure AfterConstruction; override;
    procedure BeforeDestruction; override;
    function CloseQuery: Boolean; override;
//    {$REGION 'function HandleDialogKey'}
//    /// <summary>Behandelt zentral in der TForm Tastatureingaben.
//    /// <para>MUSS in der abgeleiteten Form überschrieben werden!</para></summary>
//    /// <returns>Boolean: Tastaturereignis abgehandelt ja/nein</returns>
//    {$ENDREGION}
//    function HandleDialogKey(const Key: Word; const KeyChar: WideChar; const Shift: TShiftState;var IsDialog: boolean): boolean; virtual;
    procedure Init; virtual;

    property Viewmodel           : TsngViewmodel read FViewmodel           write FViewmodel;
    property TrackingTimerTime   : Cardinal      read FTrackingTimerTime   write FTrackingTimerTime;
    property OnTrackingTimer     : TNotifyEvent  read FOnTrackingTimer     write FOnTrackingTimer;
    property HandleEnterAsOk     : Boolean       read FHandleEnterAsOk     write FHandleEnterAsOk;
    property HandleEscAsCancel   : Boolean       read FHandleEscAsCancel   write FHandleEscAsCancel;
  end;

[mytbo]

Zitat von t2000:

Jetzt erzeuge ich ein neues Formular (vererbt von dem ersten).

Ernstgemeinte Frage: Warum willst du hier überhaupt visuell vererben? Erzeuge alles per Quelltext in einem TBaseForm und ersetze in deinen Formularen TForm durch TBaseForm. Ganz früher ging das nicht, aber seit Delphi 2007 ist das kein Problem mehr.

Bis bald...
Thomas

[himitsu]

Vererben geht, man muß nur einiges Beachten.

* der Formdesigner geht bei Fehlern zu Mammi ... wenn er was nicht erkennt, dann springt er immer auf TForm zurück
* * z.B. wenn die TypInfos in DPR/DPROJ falsch sind -> der {Kommentar} in der der UNIT in der DPR, bzw. der daraus synchronisierte <FORM>-Eintrag in der DPROJ

* im FormDesigner wird bei FormVererbung niemals deine Klasse benutzt
* * selbst dann nicht, wenn du diesen Vorfahren in ein eigenes Package kompilierst und bei Delphi bekannt machst. (RegisterComponent und/oder RegisterClass)

* im DormDesigner wird eine "virtuelle" Klasse generiert und geladen (die heißt zufällig genau wie deine Klasse, aber die RTTI wird dynamisch zusammengebaut)
* * und die RTTI wird auch immer direkt von TForm geerbt, selbst wenn dein Vorfahre mehrere Ebenen hat (weitere Vorfahren zwischen deinem Typ und TForm/TCustomForm)
* * diese RTTI hat nur den gleichen Namen und vermutlich eine Kopie der "published" Felder/Methoden, aber ohne Inhalt/Code

* das ist auch der Grund, warum überschiebene Methoden im FormDesigner nicht aufgerufen werden und warum auch niemals die eigenen Property im ObjektInspektor angezeigt werden.

* das Einzige, was im FormDesigner wirklich "vererbt" wird, sind die DFMs, also es werden erst die Komponenten des/der Vorfahren geladen, aus deren DFMs, und darüber dann die Änderungen aus der DFM der aktuellen Form eingefügt







PS:
* bei vererbten Frames kommt es drauf an, wie die auf der Form liegen
* * als Vererbung über Objektablage reingezogen, bzw. über ProjektManager oder direkt aus der PAS mit dem Frame ... dann ist alles wie bei TForm
* * oder als registrierte Komponente ... hier ist es die echte Klasse und die hat dann auch alle Property im OI und überschriebene Methoden werden ausgeführt (in deinem geladenen Package)


Besonders merkt man sowas, wenn man eine abgeleitete Form hat
und eine eigenen Komponente, welche auf Methoden/Eigenschaften der Form zugreifen will, was im FormDesigner so nie direkt funktionieren kann, da der Owner dort eben eine "andere" Klasse ist ... merkt man auch daran, dass IS/AS hier sagen das passe nicht

[t2000]

So genau wusste ich das gar nicht. Danke. Das würde zumindest das eine oder andere Problem etwas erleuchten.

Ich bin schon kein großer Freund der visuellen Entwicklung, aber gibt es hierfür bessere Alternativen?
Es geht um mehrere Programme, die alle die gleiche Basisfunktionalität und das gleiche Design haben sollen. Weiterhin müssen wir ein an MVVM angelehntes Verfahren einsetzen, da wir VCL und FMX entwickeln müssen. Nicht zu 100% identisch, aber in vielen Teilen.
Die Form-Vererbung hat unter FMX bisher keine Probleme gemacht, aber nun ist eben VCL dran. (und daran führt kein Weg vorbei, DevExpress-Grid, Fastreport, und einige weitere spezielle Dinge)

Vielleicht versuche ich mal eine Technik auf Basis von TForm, die sich Prinzipien wie interfaces bedienen. Aber die ersten Prototypen werden wir wohl erstmal so (Vererbung) oder als Cut'n Copy versuchen.

[mytbo]

Zitat von t2000:

Vielleicht versuche ich mal eine Technik auf Basis von TForm, die sich Prinzipien wie interfaces bedienen. Aber die ersten Prototypen werden wir wohl erstmal so (Vererbung) oder als Cut'n Copy versuchen.

Du suchst nach einer Lösung für ein Problem, das du mit der visuellen Vererbung selbst schaffst. Mehr als TrackingTimerTimer() zuzuweisen, machst du über den Objektinspektor nicht. Diese Zuweisung kann auch in einer von TForm abgeleiteten TBaseForm Klasse hardcodiert erledigt werden. Daher noch mal meine Frage: Warum willst du hier partout visuell vererben?

Ich definiere in einer Basis Unit eine Kaskade abgeleiteter Form-Klassen, von denen ich meine Formulare ableite. Dazu ist nur der Austausch von TForm gegen die gewünscht Klasse notwendig. Visuelle Vererbung wird dazu nicht benötigt. Ab Delphi 2007 ist dieses Vorgehen kein Problem mehr, nur ältere Versionen haben sich daran verschluckt.

Code:

TBaseForm = class(TForm)
TBaseLayoutForm = class(TBaseForm)
TBaseDataForm = class(TBaseLayoutForm)
...

Bis bald...
Thomas

[t2000]

Du hast im Prinzip Recht. Dieses oben genannte Beispiel, bzw. kein Beispiel sondern die "echte" Basis wird nicht visuell gebaut.
Bisher (vorher) hatte ich aber noch ein paar mehr Formulare. U.a. das Basis-Mainform, welches eigene Kopfzeilen mit den typischen Windowsfunktionen , Statuszeile, usw. hat. Speziell dafür werde ich mir die Vererbung auch nochmal überlegen. Bei den anderen gehe ich wohl wieder auf eine Technik mit Frames. Die kann man schön zur Laufzeit kombinieren und einfach in die Fenster (Forms) einpflanzen. Das hat schon die letzten 20 Jahre mehr oder weniger schlecht geklappt. Aber die Probleme kenne ich wenigstens alle und es funktioniert letztendlich.

[bernau]

Zitat von t2000:

Interessant vielleicht noch

Delphi-Quellcode:

    procedure AfterConstruction; override;
    procedure BeforeDestruction; override;
    function CloseQuery: Boolean; override;

aber wirklich nicht wildes drin.

Inherited in den überschriebenen Methoden vergessen?

Edit: Ähm Lese grade, daß der Fehler nicht zur Laufzeit auftritt, sondern in der IDE. Dann ist es eigentlich egal, was im Quellcode des Formulars drin steht. Der kann ja erst Fehler produzieren, wenn Compiliert ist.

Ich verwende Vererbung von Forms und Frames ständig. Wenn ich ein neues Projekt starte, wird wie bei dir erst einmal ein TBaseForm angelegt. Alle Formulare werden davon abgeleitet. Habe noch nicht wirklich Probleme gehabt. Formvererbung ist eines der Coolsten Dinge überhaupt.

[Uwe Raabe]

Kannst du mal die dproj-Datei des Projekts anhängen oder wenigstens die Einträge der beiden Forms zeigen?