Vererbung von Formularen

[charlytango]

Bin irgendwie etwas ratlos.
Für meine Report-Aufgaben habe ich seit Jahren eine Vererbungsstruktur.
In einem Formular (nennen wir es TParent) werden alle allgemeingültigen Aufgaben und Funktionen erledigt (Report designen, Report anzeigen, Daten aufbereiten etc). Im Nachfolgerformular (nennen wir es TDescendent) werden nur die individuell für einen speziellen Report nötigen Attribute gesetzt (zb SQL-Statement, Reportnamen, etc etc)

Soweit hat das ja alles geklappt und tut es im Grunde immer noch.
Nun kam ich auf die glorreiche Idee das alles etwas zu behübschen und habe im TParent auf Actionlist umgestellt, Bitbuttons statt der Buttons genommen etc.

Wie erwartet hat sich dadurch das TDescendent Formular gewehrt, daher hab ich die alten nutzlosen Buttons entfernt und alles lief scheinbar ok. 4 Buttons taten was sie sollten und nur der Close-Button tat ... nichts.

Es sieht so aus als ob der irgendwie die Verbindung zu TParent verloren hätte.
Bei Doppelklick auf den Close Button in TDescendent (also den der aus TParent vererbt wurde) in der IDE führt mich die IDE exakt zur Close-Action im Parent.
Sie müsste also wissen was der Button tun soll. Zur Laufzeit wird die Arbeit verweigert.

(mehrfaches Cleanup and Build könnt ihr voraussetzen)

Als Proof Of Conzept hab ich ein Testprojekt beigelegt, das genau das erwartete Verhalten zeigt. Im Konzept scheine ich also richtig zu liegen, aber irgend etwas hakt

Vorschläge bitte


PS (Edit): klar könnte ich in TDescendent einen Button draufkleben und ein eigenes Close auslösen, aber da bricht der Ehrgeiz durch -- elegant wäre anders

[fliegermichl]

Also bei mir passiert exakt das, was ich erwartet habe. Beide Buttons schliessen das Fenster.
Lazarus 4.0RC2 (rev lazarus_4_0RC2-37-g6d590ab2ec) FPC 3.3.1 i386-win32-win32/win64

[paweld]

In Lazarus 4.99-trunk und FPC 3.2-fixes ist alles in Ordnung, d.h. beide Knöpfe schließen das Fenster.

[charlytango]

Danke für den Einsatz, aber ....

Das Beispielprojekt liegt leider nur bei, um zu zeigen dass ich nicht ganz im Wald stehe und dass es in einem Beispielprojekt klaglos klappt.

In meiner Applikation klappt das bei vier von fünf Buttons ohne Probleme, aber meim Schließen-Button eben nicht.

Da ich nicht die ganze App raufladen kann und dürfte, bin ich auf eure Vermutungen angewiesen was da schief gegangen sein könnte.

Oder auch eine Idee wie ich die Vererbung irgendwie "refreshen" kann

[Niesi]

Bin irgendwie etwas ratlos.
Für meine Report-Aufgaben habe ich seit Jahren eine Vererbungsstruktur.
In einem Formular (nennen wir es TParent) werden alle allgemeingültigen Aufgaben und Funktionen erledigt (Report designen, Report anzeigen, Daten aufbereiten etc). Im Nachfolgerformular (nennen wir es TDescendent) werden nur die individuell für einen speziellen Report nötigen Attribute gesetzt (zb SQL-Statement, Reportnamen, etc etc)

Soweit hat das ja alles geklappt und tut es im Grunde immer noch.
Nun kam ich auf die glorreiche Idee das alles etwas zu behübschen und habe im TParent auf Actionlist umgestellt, Bitbuttons statt der Buttons genommen etc.

Wie erwartet hat sich dadurch das TDescendent Formular gewehrt, daher hab ich die alten nutzlosen Buttons entfernt und alles lief scheinbar ok. 4 Buttons taten was sie sollten und nur der Close-Button tat ... nichts.

Es sieht so aus als ob der irgendwie die Verbindung zu TParent verloren hätte.
Bei Doppelklick auf den Close Button in TDescendent (also den der aus TParent vererbt wurde) in der IDE führt mich die IDE exakt zur Close-Action im Parent.
Sie müsste also wissen was der Button tun soll. Zur Laufzeit wird die Arbeit verweigert.

(mehrfaches Cleanup and Build könnt ihr voraussetzen)

Als Proof Of Conzept hab ich ein Testprojekt beigelegt, das genau das erwartete Verhalten zeigt. Im Konzept scheine ich also richtig zu liegen, aber irgend etwas hakt

Vorschläge bitte


PS (Edit): klar könnte ich in TDescendent einen Button draufkleben und ein eigenes Close auslösen, aber da bricht der Ehrgeiz durch -- elegant wäre anders

Hast Du alle "Erbstränge" durchgesehen? Ich meine damit "inherited", "override" usw. - es scheint ja so, dass Deinem Close-Button da was nicht komplett duchvererbt wurde ...

[charlytango]

Ja habe ich.
In besagtem Button steht wie erwartet überhaupt kein Code. Alles wie es sein sollte.

Der Treppenwitz ist auch dass die anderen beiden abgeleiteten Formulare wie erwartet funktionieren.

Werde demnächst Mal ein neues Formular ableiten und man das *.lfm vergleichen. Grübel.

Gibt es in der GUI irgend eine Möglichkeit so ein abgeleitetes Formular zu "reparieren" ?

[Joh]

Also bei mir gab es teilweise ähnliche Probleme bei (angepaßten-) abgeleiteten Formulare.
Gefühlt würde ich sagen: in der Ereignisprozedur des abgeleiteten Formulars steht etwas drin, aber nicht der Zugriff auf das Parent.
Bei mir hat es geholfen, den Eintrag in der Ereignisprozedur zu löschen und neu anzulegen.

IMHO werden teilweise bei abgeleiteten Formularen /auch bei Datenmodulen die Einträge, die in den lfm-Dateien stehen, nicht korrekt gelöscht/aktualisiert.

Das passiert scheinbar dann, wenn man "bewußt" mehrere Fehler einbaut, wie Felder aus dem abgeleiteten Formular in das Parent-Formular übernimmt, dann die anderen abgeleiteten Formulare durchgeht.
Bei machem Formular (einem von zwei fast identischen) meckert der Kompiler nicht, sondern der Funktionszeiger zeigt ins Nirvana.

Die Ereignisprozedur im abgeleiteten Formular löschen, neu anlegen, Bestätigen, das es sich auf die inherited-Funktion bezieht und fertig.

[af0815]

Wenn sowas bei m ir auftraucht, so sehe ich mit im abgeleiteten Formular die lfm an. Da kann es sein, das eine hängende Eventprocedure gibt. Das ist so ähnlich auch mit den Frames zur Designzeit. Einmal die lfm korr. und dann ist das Problem meistens gegessen.

[charlytango]

@Joh @af0815
So etwas in der Art hatte ich eh auf dem Schirm und wenn alle Stricke reißen leite ich einfach ein neues Formular ab. Das sind nur ein paar Zeilen Code.

Es ging mir eher darum, es auch zu verstehen und zu finden. Leider kam ich noch nicht dazu die .lfm genauer anzusehen, aber das passiert noch.

Scheinbar gibt es auch keine Funktion die so etwas repariert, denn die eingebaute scheint ja von zeit zu zeit nicht ganz korrekt zu funktionieren

Jedenfalls erstmal danke für den Input.

[af0815]

Die lfm sollte man sich einmal generell ansehen, da gibt es ein paar Kleinigkeiten die man wissen sollte (ich aber nirgends dokumentiert gefunden habe). Am besten ein Testprojekt, einmal mit vererbten Formular einmal ohne und dann einfach nur sehen was unterschiedlich ist.

Beim vererben wirst du ähnliche Erscheinungen haben, wie bei den FRames zur Designzeit - du siehst Änderungen (am Elterformular) erst, wenn du das Formular mit der Vererbung einmal schliesst und wieder öffnest (oder das Projekt neu öffnest).

Wenn du im Kind ein Ereignis des Elternformulars überschreibst und später wieder löscht, musst du das auch in der lfm manuell ändern, weil dort das Ereignis stehen bleibt.
Aha, da hat sich ein wenig was getan, man wird bei erstellen gefragt ob man das Ereignis überschreiben will.

Löscht man das Ereignis aus dem Kind, bleibt folgendes in der lfm aber stehen

inherited Button1: TButton
OnClick = nil
end

Und genau das muss man löschen, das kann der Editor nicht (oder ich weis nicht wie)