Organisieren von großen Programmen

[rweinzierl]

Hallo

Mein persönlicher Ansatz bei einem Formular mit vielen Pagecontrols den Code in einzelne Formulare zu trennen und diese dann ähnlich wie Frames auf dem Hauptformular zusammenzufassen.

Delphi-Quellcode:

myFrm:= TmyFrm.Create(Application);
myFrm.Position := poDefault;
myFrm.Parent := EinesDerTabsheets;
myFrm.BorderStyle := bsNone;
myFrm.Left := 0;
myFrm.top := 0;
frmVentilatorECZuluft.show;

Natürlich trennt man trotzdem Code und Darstellung, aber so habe ich nicht alles in einem Monster Formular und trotzdem für den Anwender alles schön kompakt.

mfg

Reinhold

[stahli]

Ich hatte kürzlich hier einmal zur Zweckmäßigkeit von Frames nachgefragt und angefangen, das so umzusetzen.
Jeder dieser Frames wird nur einmal im Projekt eingesetzt und soll lediglich einer Trennung von inhaltlichen Bereichen in einzelne Units dienen.

Mich nervt dabei, dass man die Frames dann aber auch in der Mainform hat und daran (un-)absichtlich herumschrauben kann. Grundsätzlich würde ich mir wünschen, dass die IDE Frames optional nur als graues Panel darstellt und nur zur Laufzeit mit Leben füllt.

Die Idee mit eingebunden Formularen klingt aber auch gar nicht schlecht... Werde ich heute Abend mal antesten.
Welche Vorzuge gegenüber Frames kann man denn grundsätzlich nennen?

[rweinzierl]

Vorteile:


Das Formular kann "normal" entwickelt und getestet werden, und bei bedarf auf "im Hauptformular angeklebt" abgeändert werden.

Formulare haben ein Formcreate ... (Frames glaube ich nicht)

Formulare funktionieren seit Delphi 2.0 ziemlich fehlerfrei. ( Zumindest meistens )

...

mfg

Reinhold

[Bummi]

@stahli
Du kannst Deine Formulare, gedockt und ungedockt verwenden, Du brauchst bei u.g. Vorgehen kein Tabsheet für das Formular vorsehen, es entsteht beim docken automatisch.
Ansonsten wenn Du Dir die Properties und Events der Forms anschaust ....

Delphi-Quellcode:

    TTestsF.Create2(KundentestsF,@TestsF);
    TestsF.Show;
    TestsF.ManualDock(KundentestsF.PC,nil,alnone);

wie Eingangs in diesem Thread erwähnt ist dies die seit 10 Jahren bei mir bevorzugte Methode.

[Assarbad]

Übrigens, was hier in diesem Thema angesprochen wird, ist genau das was ich immer so erkläre: Delphi und CB verleiten zu schlampigem Programmieren.

Auch wenn es Delphianer ungern hören, wenn man in Delphi mit Forms usw. programmiert muß man unheimlich diszipliniert sein um nicht in den Spaghetticode abzugleiten zu dem einen die IDE verleitet. Wer schonmal solchen Code warten durfte (und ihn vorher nicht selber verbrochen hatte), der wird mir unumwunden zustimmen.

Was ich damit meine ist u.a., daß man nicht einfach "drauf los" programmieren und die Ereignisbehandlungsroutinen direkt bestücken sollte, sondern lieber die Logik auslagern und von der GUI trennen sollte (was ja hier vorher schon angesprochen wurde).

(C# mit WinForms ist in der Hinsicht übrigens ähnlich)

[mquadrat]

@Assarbad

Das ist doch überall so ähnlich. Delphi DFM + PAS entspricht ja in etwa auch WPF XAML + Code Behind.


@Aufteilen in mehrere BPLs / DLLs

Das steht bei mir demnächst auch an, funktoniert aber nur dann halbwegs schermzfrei wenn alles lose gekoppelt ist. Nebenfrage: Ist eigentlich Code Insight schneller, wenn man den Code aufteilt oder wird doch wieder alles compiliert? Das nervt mich aktuell am meisten, IMHO wird da viel zu oft viel zu viel compiliert. Mir würde es vollkommen langen den letzten Compilierungs-Stand (manuelles Compilieren) im Code-Insight zu haben. Aber gut jetzt wird's dann doch Off-Topic.


@Frames

Frames sind irgendwie nichts halbes und nichts ganzes. Eine Black-Box wäre mir da mitunter wirklich lieber. Um Frames auch als Formular aufrufen zu können, hab ich mir immer einfach ein Wrapper-Formular geschrieben, in das man eben den Frame injecten konnte.

[Assarbad]

Zitat von mquadrat:

Das ist doch überall so ähnlich. Delphi DFM + PAS entspricht ja in etwa auch WPF XAML + Code Behind.

WPF ist für mich auch nur WinForms weitergedacht

Einerlei. Das war auch nicht was ich meinte. Delphi und CB verleiten dazu den Code gleich in die Ereignisbehandlungsroutine zu klimpern, was man aber tunlichst vermeiden sollte, wenn man Logik und Präsentation auch nur ansatzweise trennen will. Die meisten Codebeispiele zeigen aber leider genau diesen Stil. Und erfahrungsgemäß überwiegt er auch. Keine Ahnung was man an Delphi ändern könnte um das zu entschärfen, aber ich sehe das als eines der Probleme (neben dem Hersteller ).

[mquadrat]

Zitat von Assarbad:

Das war auch nicht was ich meinte. Delphi und CB verleiten dazu den Code gleich in die Ereignisbehandlungsroutine zu klimpern, was man aber tunlichst vermeiden sollte, wenn man Logik und Präsentation auch nur ansatzweise trennen will. Die meisten Codebeispiele zeigen aber leider genau diesen Stil. Und erfahrungsgemäß überwiegt er auch. Keine Ahnung was man an Delphi ändern könnte um das zu entschärfen, aber ich sehe das als eines der Probleme (neben dem Hersteller ).

Jep interessanterweise mache ich das selber in Delphi auch oft so, während ich unter .NET nicht den Drang verspüre. Aber dort benutze ich auch ein MVVM Framework. Ich denke mal ein Problem ist das becheidene Databinding in Delphi. Man muss dauernd Glue-Code schreiben. Und wenn da schon Code drin steht, dann schreibt man eben nochmal was dazu. Ist ja nur eine Kleinigkeit. Und noch eine Kleinigkeit. Und noch eine.

Oder es liegt daran, dass das .DFM versteckt wird und es daher gar nicht so den Eindruck macht, man würde jetzt im Formular arbeiten.

Oder es liegt daran, dass bei Delphi gesagt wird "blöd" wenn man Code im Formular hat, während man von der .NET Gemeinde erschossen, ertränkt und danach viergeteilt wird. Allein schon wenn man wagt nachzufragen ob ein MVVM denn immer Sinn macht

Aber jetzt wird's OT. Sorry.