Organisieren von großen Programmen

[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:

Zitat von mquadrat (Beitrag 1063782)

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 :stupid:

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 :zwinker:).

[nachti1505]

Zitat:

Zitat von sx2008 (Beitrag 1063662)

Du teilst die Unit "Utilities" in mehrere Units mit unterschiedlichen Themengebieten (Stringverarbeitung, Datenbankzugriff, Verschlüsselung, ...) auf.
Zum Schluss hast du eine Bibliothek bestehend aus versch. Units, die du auch in anderen Anwendungen einbinden kannst.

Ich nehme an, diese Unit binde ich dann nur per uses ein, oder? Was wäre denn der Unterschied zum Hinzufügen zum Projekt? Bzw. was ist generell der Unterschied zwischen uses und einbinden?

[Assarbad]

Zitat:

Zitat von nachti1505 (Beitrag 1063820)

Ich nehme an, diese Unit binde ich dann nur per uses ein, oder? Was wäre denn der Unterschied zum Hinzufügen zum Projekt? Bzw. was ist generell der Unterschied zwischen uses und einbinden?

Ich sehe da keinen Unterschied. Dem Linker mußt du doch trotzdem noch sagen was er zusammenlinken soll. Also irgendein Teil deines Codes wird wohl zwangsläufig die Unit per uses einbinden (bspw. von der .dpr aus).

[mquadrat]

Zitat:

Zitat von Assarbad (Beitrag 1063796)

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 :zwinker:).

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.