1 Formular auf mehrere Units verteilen

[matthes]

Moin,

Ich möchte ein Formular mit zugehöriger Unit, die langsam etwas unübersichtlich wird, in mehrere Units aufteilen.

Ich nehme mal als Beispiel ein Tab-Control mit mehreren Registern in Form0 mit Unit0.
Nun soll das Ereignis für Button.OnClick in Register1 in Unit1 geschrieben werden und bei Button.OnClick in Register2 soll dieses in die Unit2.


Man könnte es wahrscheinlich so machen, dass man das OnClick-Ereignis in Unit0 deklariert, in der Procedure Form0.Click dann auf eine Procedure in Unit1 oder Unit2 verweist, die dann die Arbeiten ausführt (auch mit Form0 Zugriff).

Aber ich möchte, daß in Unit1 so gut wie nix drin steht.

Ich hoffe, ich habe mich halbwegs verständlich ausgedrückt.
Hat jmd. eine Idee, wie und ob das zu realisieren ist ?

Grüße

Matthias

[Muetze1]

So nicht ohne weiteres. Ich sehe mögliche Lösungen durch:

a) Include Dateien (meist nicht debugbar, schlecht handlebar)
b) Frames (erhöht die Modulariesierung und entspräche dem OOP Design)

[matthes]

Das ging ja schnell :-)

Aber wird der Quelltext für Frames in einer extra Unit ausgelagert ?
Ich dachte ein Frame ist nur eine gespeicherte Gruppierung von Formular-Elementen, ohne Quelltext.

Ich hatte zuerst an irgendwelche Vererbung, Ableitung bzw. Zeiger auf Formular setzen gedacht, aber das funktioniert ja auch nicht.

[DGL-luke]

Ein Frame kann durchaus auch Code enthalten. Meiner Ansicht nach sollte ein Frame aber "ganz unten" liegen, d.h. er sollte an den Rest des Formulars nur Daten ausgeben. ich habe zum beispiel frames gemacht als Header+Footer eines Forms oder Frames mit den "OK, Apply,Cancel" Buttons für einen Dialog oder einen "Datei öffnen Frame" mit Edit und Button.

Größeren Code, der über das Umformatieren von Benutzereingaben hinausgeht, habe ich aber nie drin.

[Muetze1]

Zitat:

Zitat von matthes

Aber wird der Quelltext für Frames in einer extra Unit ausgelagert ?
Ich dachte ein Frame ist nur eine gespeicherte Gruppierung von Formular-Elementen, ohne Quelltext.

Es ist eigentlich wie eine Sonderform eines Formulars - mit den Elementen, die Ereignismethoden, etc. Darin kannst du diese auch schon soweit programmieren.

[mr.unbekannt]

nach meinem wissen nach, solltest du die onclick-ereignisse usw. auf der unit1 (Form1) aufrufen und dann kannst du die doch auf vielen units verteilen. Bsp.

Delphi-Quellcode:

procedure TForm1.button1Click(Sender: TObject);
begin
unit3.button1click;
bzw. unit3.sowieso
end;

mfg

[Muetze1]

Zitat:

Zitat von mr.unbekannt

nach meinem wissen nach, solltest du die onclick-ereignisse usw. auf der unit1 (Form1) aufrufen und dann kannst du die doch auf vielen units verteilen. Bsp.

Delphi-Quellcode:

procedure TForm1.button1Click(Sender: TObject);
begin
unit3.button1click;
bzw. unit3.sowieso
end;

mfg

Ich hasse solche Codes. Und 2 Wochen später sitzt man stundenlang an solchen Projekten "weil irgendwas nicht mehr läuft" und man sieht wegen dem kreuz- und quergeschiesse nicht mehr durch. Da debuggt man erstmal 3 Tage um rauszufinden wer alles aus welchen versteckten Ecken eine Procedure/Methode aufruft.

Grässlich.

Ich kann sowas nicht unterstützen - aber auch nicht verhindern - aber wenigstens meinen Senf dazu abgeben...

[matthes]

Zitat:

nach meinem wissen nach, solltest du die onclick-ereignisse usw. auf der unit1 (Form1) aufrufen und dann kannst du die doch auf vielen units verteilen. Bsp.

Ja, daran habe ich auch schon gedacht, aber hatte auf eine "schönere" Lösung gehofft.
Ist aber jedenfalls besser als alles in eine Unit zu schreiben.

Ich habe es eben mal kurz mit einem Frame probiert. Es funktioniert soweit, daß der Code des Frames ausgeführt wird, aber könnte ich auch von Frame1 auf Frame2, von Frame1 auf normale Form, ... zugreifen ?

Aber vielleicht kennt ja noch jemand eine elegantere Lösung.