Organisieren von großen Programmen

[divBy0]

Was ist denn mit Packages und BPL?

[himitsu]

Zitat von divBy0:

Was ist denn mit Packages und BPL?

BPL ist auch "nur" eine DLL (mit speziellen Delphizusatzfeatures).
Also hier gilt das Selbe, wie bei den DLLs.
Wenn man das für nur ein Projekt macht, bringt es wohl nicht wirklich Vorteile.
Und bei Verwendung in mehreren Projekten muß man hier zusätzlich aufpassen.

PS: Die BPL muß mit dem selben Delphi-Compiler und der selben RTL/VCL-Version kompiliert sein, wie die EXE, welche sie verwenden will,
da ja die selben RTTI-Informationen verwendet werden müssen.
Dagegen ist eine "normale" DLL natürlich unabhängiger.

Wenn du also 2 Programme hast, welche die "gleiche" BPL nutzen will, aber das eine Programm noch in D2006 geschrieben ist, aber das andere Programm schon mit D2007, dann müssen auf dem Zielsystem irgendwie die BPLs für beide Delphiversionen installiert/vorhanden sein.
Und wenn das nun die einzigen Programme sind, welche diese BPLs nutzen, dann ist doch der Aufwand damit größer?

[BlueLiquidCell]

Hey
Bei den Forms ist halt das Problem das ich die Variablen dann nur in der Form(auf der Tab seite) benutzen kann, bräuchte sie aber manchmal auch global.

Das mit den Klassen hört sich doch nach relativ viel aufwand an, vorallem weil ichs nicht von anfang an eingeplant hab ist aber wohl ne relativ gute Lösung wenn man noch länger an dem Programm arbeiten will. Muss ich mir aber erstmal genau angucken weil ich damit noch nicht wirklich was gemacht hab.

Vorteil von dlls gegenüber auslagern in ner pas ist doch dass das Hauptprogramm kleiner wird und er die dll nur läd wenn ers braucht. Oder seh ich das falsch?
StaticLibrary wär natürlich auch ne idee.
Bezüglich des debuggen hab ichs immer so gemacht das ich zunächst eine Funktion im Hauptprogramm ausprobiert hab und nachdem alles lief die funktion in die dll gepackt hab. Dann entfällt nachträgliches debuggen meistens.

Merci, für die vielen Antworten und anregungen
Christoph

[joachimd]

Zitat von BlueLiquidCell:

Bei den Forms ist halt das Problem das ich die Variablen dann nur in der Form(auf der Tab seite) benutzen kann, bräuchte sie aber manchmal auch global.

Dann gib diese als Property in deine Form-Klasse und lese sie auch so wieder zurück. Vorteil davon: Du kannst richtig schön Formular für formular entwickeln und unabhängig(!) voneinander testen. Am Besten noch von einem gemeinsamen Vorfahren abgeleitet, damit du einzelne Methoden/Properties schonmal voraussetzen kannst (ohne tausender TypeCasts).

[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

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