Fragen zu Umgang mit Packages und Forms

[Hansa]

Zitat von DJ-SPM:

Also müsste ich in diesem Fall für jedes neue Package auch die Zeos-Komponente einfügen und die Einstellungen neu setzen?

Eben nicht. Genau das ist der Witz ! Das ganze ist auch als "Repository" bekannt. Vergiss nur eben Packages im Zusammenhang mit Forms. Nimm leere Form und packe eine DB-Komponente da drauf, z.B. ein DataSet. In diesem stellt man jetzt alles ein, also die Database, Transaction, SQLs usw. rechter Mausklick -> "der Objektablage hinzufügen" Titel : DBForm und vererben. Letzteres ist wichtig um OOP richtig zu nutzen !! Das Ding mit allen Voreinstellungen steht jetzt zur Verfügung. Von mir aus packe noch Labels, Buttons, Listboxen, DBEdits usw. da drauf. Hier kommt nun aber tatsächlich eine gewisse Hierarchie ins Spiel. Überlege zuerst mal, was auf jeden Fall in einer Form zu sehen sein soll. Bei mir ist das zumindest eine Überschrift, das Datum, die Stations-Nr., also 3 Labels und ein Panel. Von dieser Form geht jetzt einiges aus.

So, nun willst Du aber auch noch ein Dataset haben und sagen wir mal ein Stringgrid ? Die vorbereitete Form ist ja bereits im Repository. Also sage ich nicht neu -> Form, sondern neu -> weitere und suche mir die vorbereitete Form. Und sieh an, alles ist da. Das Datum usw. steht bereits da drauf und zwar schon gleich an der richtigen Position. Die Überschrift ist in der richtigen Größe und Farbe schon da usw. Ab jetzt gehts dann Schlag auf Schlag. Dataset ? Auf Form setzen, OI bestücken und gleich noch das Stringgrid. und wieder : rechter Mausklick -> ab in Objektablage.

So nun brauche ich eine Adressliste ? Ich nehme diese Form aus der Objektablage. Und lediglich folgendes wäre noch zu tun : SQLs des bereits vorhandenen DataSets anpassen und dann die Bestückung des Stringgrids. Alles andere wird geerbt von der Vorfahr-Form. Das gilt übrigens auch für Ereignisse. Bereits in meiner Urform ist z.B. geregelt, daß man mit ESC die Form schließen kann und auch mit Enter ins nächste Feld komme. Um solchen Kleinkram kümmere ich mich jedenfalls nur einmal und danach nie wieder.

[TheMiller]

Hm, das ist ja alles gut und schön. Aber im Endeffekt habe ich doch dann trotzdem auf jedem Form die Datenbankkomponente. Es geht mir nicht darum, für jede Form die Datenbankkomponente neu einzurichten, es geht mir darum, dass ich einmal eine Komponente habe und auch nur einmal zu Server connecten muss und die jeweiligen neuen Module auf diese Komponente zugreifen können.

Von mir aus besteht das Programm aus 10 Teilen. Eine Hauptapplikation MIT DB-Kompo und 9 Module in Package-Form. Diese 9 Module sind Erweiterungen, die nicht Pflicht sind, aber auch nicht alleine laufen sollen. So sollen diese 9 Module die DB-Kompo auf Form1 und die somit schon bestehende Verbindung nutzen und über Form1 mit dem Server kommunizieren...

Was du beschrieben hast ist zweifellos nützlich, aber hat, so wie ich es verstanden habe, nichts mit dem zu tun, was mein Problem ist...

Oder verstehe ich dich da falsch?

[Hansa]

Zitat von DJ-SPM:

Oder verstehe ich dich da falsch?

So siehts aus. 8) Da sogar unbestrittenermaßen gestandene Programmierer nicht genau wissen, wie so was geht habe ich das Thema abgehakt und benutzte diese Fähigkeit von Delphi nur selber.

[TheMiller]

... Verstehe es trotzdem net...Kannst ja auch mal ein Video-Tut wie alcaeus machen *g*

[negaH]

Ich habe so den Eindruck das ihr aneinander vorbei redet.

Hansa erklärt einen Weg wie man Formulare über Vererbungen in seinen Projekten besser nutzen kann. Dies kann man in Single-EXEs, DLLs oder eben auch Package basierten Anwendungen.

Der letzter Fall ist die eigentliche Frage, nämlich das WIE.

Zuerst organisierst du mal eine Anwendung strukturell:
1.) Hauptform, mit Menusystem, Registrations Funktionen deiner exterenen Module
2.) Basis Datamodul das den Erstzugriff auf deine DB über ZEOS initialisiert und ansonsten einige Standard Dataset enthalten kann.

All dies baust du in ein Package mit zb. Namen Main.bpl rein. Da das ein Package ist müssen somit auch alle Komponenten wie VCL und eben ZEOS ebenfalls als Packages vorliegen !

Dann baust du deine Main.EXE. Diese ist eine EXE die nur Eines macht, sie bindet dein Main.bpl ein und erzeugt dein TMainForm + TDataModul daraus. Mehr nicht. Diese EXE wird ca. 30-70Kb groß sein.

Und jetzt möchtest du deine eigentlichen Formulare bauen. Dazu musst du eine DLL erzeugen in die du zb. dein neues TForm1 aus der Unit Unit1.pas einfügst. In den Projektoptionen angeben das mit Packages gearbeitet werden soll und dort auch die packages Main und Zeos angeben.

In deiner Unit1.pas kannst du nun ganz einfach die Unit MainForm.pas auf dem Package Main.bpl in die Uses Klausel aufnehmen. Dein TForm1 aus Unit1 hat also direkten Zugriff auf das TMainForm aus der Unit MainForm.pas im Package Main.bpl. Du arbeitest quasi so als hättest du eine Single EXE Anwendung.
Das gleiche geht mit deinem TDataModule das ebenfalls in Main.bpl initegriert wurde.

ABER! Alles was du ins Main.bpl reinbastelst solltest du nicht ständig im Interface verändern, da dies dazu führt das alle davon abhänigen Module neu compiliert werden müssen.

So, in dieses Konzept kannst du nun auch wiederum Hansa's vererbte Formulare benutzen. Das Basis Formular kämme dan n in das Package Main.bpl und zu diesem Main.bpl (das ja Runtime-only ist) benötigen wird noch ein DclMain.bpl. Dieses ist der DesignTime-Part zu Main.bpl und wird in die Delphi IDE installiert. Somit kannst du nun direkt weitere Formulare von alle den in Main.bpl enthaltenen Basis-Forms ableiten und vererben.
Das geht, und ich habe das schon im D3 einige Monate in unserer Packagebasiertem Frame benutzt. Allerdings lernten wir sehr schnell das zumindestens in D3 diese Vorgehensweise enorm instabil und wenig praktikabel in der Entwicklung eines Teams ist. Der Große Vorteil dieser Forms ist nämlich immer dann wenn man eigene Frmenstandards in Punkto Styling etc. durchsetzen möchte. Alle Programmierer müssen dann solche Repositories benutzen.
Auf Grund der Schierigkeiten im D3 bei der korrekten Einbindung der nun ebenfalls vererbbaren DFM Resourcen, denn nun besteht eine DFM aus 2 DFMs die un unterschiedlichen Resourcen unterschiedlicher Module gespeichert sind die D3 eben nicht korrekt laden konnte, haben wird es einfach über normale Klasssenvererbung gemacht. Alle wichtigsten Änderungen wurden in eine neue Klasse wie TWin95Form eingebettet und diese in das Main.bpl als Klasse eingebunden. Alle Modul-Forms mussten dann diese Klasse als Vorfahr angeben. Dies ist wesentlich stabiler in der Produktion als mit Repositories zu arbeiten.

Gruß Hagen

[TheMiller]

Danke,

ist aber ein ganz schöner Aufwand. Ich hoffe ich hab das jetzt richtig verstanden. Wenn weitere Probleme auftreten, melde ich mich wieder...

[Hansa]

Zitat von DJ-SPM:

..ist aber ein ganz schöner Aufwand...

Wo ist denn da der Aufwand ? Gut, der besteht schon darin, das mal zu testen und das muß man mal machen. Aber sonst ? Wenn Hagen sagt, bei D3 wäre das nichts richtiges, so sage ich : teste die Objektablage, weil : was soll ein Package für Vorteile haben ? Vielleicht war das wirklich mal Schrott. Ist es aber nicht mehr !