Laufzeit Package und z.B. ZeosConnection

[Tyler]

Hallo!

Hab mich jetzt mal endlich an die Package-Nutzung herangewagt, und mir 2 englische Tut's dazu (verlinkt aus diesem Thread) durchgelesen.

Das Erstellen und Nutzen grundsätzlich funktioniert auch ganz gut, doch jetzt will ich eine ZConnection dynamisch nutzen, da ich die öfter mal brauche.

Dazu folgende Fragen:

1. Ist es sinnvoller (A) die ZConnection-Komponente auf einer Form zu platzieren oder (B) zur Laufzeit der Unit mit Create zu erstellen? (Ich gehe stark von (B) aus...)

2. Wie ich das Package in mein HauptProggi einbinde ist klar, nur wie verweise bzw nutze ich jetzt die ZConnection in diesem Package? Wie kann ich meinen Query z.B. diese ZConnection zuweisen?

Hoffe mir kann jemand helfen!

Danke im Voraus

tyler

[Tyler]

Also ich verzweifel beinahe... mit Müh und Not hab ich nur ein mittelgrosses Projekt zusammengeschustert, und zwar rein schematisch folgendermassen:

Package1: Connectivität zum MySQL-Server (Zeos) in einer Unit

Package2: benutzt Package 1 und liefert in Unit1 (DataModule) die SQL und DataSource-Komponenten, und in Unit2 das DBGRid samt irgendwelcher VCL-Kompos. VCL benutzt Unit1. Unit1 benutzt aus Package1 die Unit.

jedenfalls in der Theorie. In einem Sample hat das ganze wunderbar funktioniert, nur halt eben mit mit den BDE-Komponenten von Delphi. Wie bewege ich jetzt Unit1/Package2 dazu die Zeos COnnection aus Unit1/Package 1 zu nutzen?


Ich sitz hier grad n bisserl hilflos

tyler

[Tyler]

Bin ich der einzige Delphi-Coder der sich mit Packages beschäftigt oder hab ich mein Problem so umständlich beschrieben

egal, nach ein paar Stunden rumknobeln, hab ich es nun geschafft, mit 2 Packages zu arbeiten.

Package1 (P1) enthält die ZConnection-Komponente.

Package2 (P2) enthält die Form samt ZQuery, DataSet und DBGrid. Hier ist P1 unter uses angegeben, damit die ZQuery auf die ZConnection zugreifen kann.

Anwendung1 (A1) das Hauptprogramm. von hier aus wird P2 aufgerufen (bzw. die darin enthaltene Form)

Soweit die Theorie. Nun will ich aber ähnlich P2 noch eine Package erstellen, P3, in welchen eine ander ZQuery-Komponente auf P1 zugreifen soll.
Ausserdem soll P3 auch auf P2 zugreifen können.

Da gibts nun die Fehlermeldung: Die Packages P2 und P3 enthalten beide Unit u_standard (Anm. Die unit aus P1)

Na toll. Heisst das also, ich kann jeweils ein Package immer nur von einem anderen benutzen, und niemals mit 2 gleichzeitig? Wo liegt da dann am Ende der Vorteil

Jemand hierfür vielleicht ne Idee?

Danke
tyler

[Bernhard Geyer]

Zitat von Tyler:

Na toll. Heisst das also, ich kann jeweils ein Package immer nur von einem anderen benutzen, und niemals mit 2 gleichzeitig? Wo liegt da dann am Ende der Vorteil

Jemand hierfür vielleicht ne Idee?

Du mußt dafür sorgen das jede Unit nur in einem Package eingebunden ist und wenn es ein anderes Package diese auch benötigt, das dann das erste Package im requires-Abschnitt der ersten Unit steht.

Aber wieso ärgerst Du dich den mit Packages rum? Kompiliere doch alles in eine Anwendung und spare dir doch diese Verkomplizierung. Und wenn du auch noch komplett ohne Laufzeitpackages arbeitest kommst Du mit einer Exe aus die alles enthält - keine tausend Dateien oder Versionskonflikte.

[Robert_G]

Zitat von Tyler:

Na toll. Heisst das also, ich kann jeweils ein Package immer nur von einem anderen benutzen, und niemals mit 2 gleichzeitig? Wo liegt da dann am Ende der Vorteil

Jemand hierfür vielleicht ne Idee?

Der Trick ist einfach beide Packages niemals direkt voneinander abhängig zu machen.
Hast du eine Klasse, die in beiden benötigt wird, dann lege sie in ein zusätzliches Package.
Jetzt können beide ungehindert die Informationen aus diesem laden.

Zitat von Tyler:

Bin ich der einzige Delphi-Coder der sich mit Packages beschäftigt oder hab ich mein Problem so umständlich beschrieben

Nein bist du nicht, dein Thread ist mir nur bisher entgangen.
Falls ich heute abend mit Zeit gesegnet bin, schaue ich mir dein Problem mal an.

Zitat von Bernhard Geyer:

Aber wieso ärgerst Du dich den mit Packages rum? Kompiliere doch alles in eine Anwendung und spare dir doch diese Verkomplizierung. Und wenn du auch noch komplett ohne Laufzeitpackages arbeitest kommst Du mit einer Exe aus die alles enthält - keine tausend Dateien oder Versionskonflikte.

Das klingt wie die Ausreden eines VB'lers wrum er gar keine Vererbung lernen braucht.
Packages sind einer DER Vorteile von Delphi. Sie lohnen sich schon bei mehr als einer Echse pro Projekt.

Wer sich mal mit .Net befasst hat wird merken, dass sich die Assemblies weniger an MS' TypeLibs sondern vielmehr an Delphis Packages orientieren.

[Tyler]

Erstmal vielen Dank für eure Antworten

Zitat:

Du mußt dafür sorgen das jede Unit nur in einem Package eingebunden ist und wenn es ein anderes Package diese auch benötigt, das dann das erste Package im requires-Abschnitt der ersten Unit steht.

Also als Beispiel:
Package1 - Hauptprogramm
Package2 - bietet einige Standard-Ressourcen, die ich immer wieder brauche - wird in P1 nicht erwähnt
Package3 - wird nun vom Hauptprogramm aufgerufen, und greift auf P2 zu
Package4 - wird auch vom Hauptprogramm aufgerufen, und benötigt auch P2 (wie gesagt, es geht mir um z.B. die ZConnection) - und in P4 soll jetzt P3 als "required" festgelegt werden, hab ich das richtig verstanden?

Zitat:

Aber wieso ärgerst Du dich den mit Packages rum? Kompiliere doch alles in eine Anwendung

Den Grund hat Robert ja schon wunderschön dargeboten. Es geht einfach nicht mehr. Mein Programm belegt mittlerweile eine Menge Speicher, und ein Grossteil davon wird einfach nicht permanent benötigt. Ausserdem gestaltet sich auch das Updaten mit Packages um einiges leichter!

Zitat:

Der Trick ist einfach beide Packages niemals direkt voneinander abhängig zu machen.
Hast du eine Klasse, die in beiden benötigt wird, dann lege sie in ein zusätzliches Package.

Aber so hab ich es doch gemacht. Mein Problem ist jetzt, wie oben schon erwähnt, dass das ganze Programm aus einigen vielen Modulen besteht. Und diese Module rufen sich untereinander auch auf. Daher "musste" ich sie untereinander verknüpfen - was ja zum Fehler führt.
Welche Möglichkeit hätte ich sonst, dass ein Package seinerseits ein anderes aufruft? Mir käme da höchstens noch in den Sinn, dass ein Package über eine Routine des Hauptprogramms ein anderes startet. Dazu müsste aber das Hauptmodule im USES-Bereich stehen...

naja, ich probier das morgen nochmal aus!

Vielen Dank erstmal für eure Anteilnahme

tyler

[Bernhard Geyer]

Zitat von Robert_G:

Das klingt wie die Ausreden eines VB'lers wrum er gar keine Vererbung lernen braucht.
Packages sind einer DER Vorteile von Delphi. Sie lohnen sich schon bei mehr als einer Echse pro Projekt.

Also VB habe ich auch schon hassen gelernt. Und man kann auch ohne Package-Konzept mit Vererbung arbeiten.
Wie seine Verteilung aussieht, wird er eh immer mit jedem Update des Programmes so ziemlich alle Packages neu verteilen müssen, da er ja in allen Packages erweiterungen vornehmen wird.
Selbst verwende ich keine Packages um bei einer Verteilung nicht hunderte Dateien mit verteilen zu müssen.

Zitat von Robert_G:

Wer sich mal mit .Net befasst hat wird merken, dass sich die Assemblies weniger an MS' TypeLibs sondern vielmehr an Delphis Packages orientieren.

Es wurden ja auch einige Nachteile/Mängel der Delphi-Packages behoben, so das man hier problemlos mehrere Versionen im globalen Assembly-Cache haben kann, ohne in die DLL-Hölle zu geraten. Probier das mal mit verschiedenen Versionen einer vcl60.bpl im System-Verzeichnis.

Zitat von Tyler:

Den Grund hat Robert ja schon wunderschön dargeboten. Es geht einfach nicht mehr. Mein Programm belegt mittlerweile eine Menge Speicher, und ein Grossteil davon wird einfach nicht permanent benötigt.

Wie groß ist den dein Programm. Ich habe auch schon Delphi-Exes mit 10 MB ohne Problem auch noch unter Win95 mit 64 MB laufen. Und das Programm benötigt mit DB-Anbindung, XML, Unicode und vollständigen XP-Support auch "nur" 30 MB Speicher wenn es geladen ist.

Zitat von Tyler:

Ausserdem gestaltet sich auch das Updaten mit Packages um einiges leichter!

Eine Exe tauschen gestaltet sich m.E. viel einfacher als das Tauschen von mehreren Dateien, wobei diese immer in kompatiblen Versionen zueinander gehalten werden müssen (DLL-Hölle).

[Tyler]

Naja, das Programm reicht schon an die 20 MB Grenze heran. Es geht nicht nur um die Ressourcen, sondern einfach auch um die bessere Verteilung. Ich find's sinnvoller schnell mal ein Package auszutauschen, als ein 20MB Exe-Datei durch die Leitung zu schieben.
Ist ja auch egal, ist halt Geschmackssache. Und irgendwo will ich auch einfach dieses verflixte Problem lösen, und jetzt nicht aufgeben und sagen: Ich brauchs ja nicht so dringend

Zum Thema nochmal eine Frage:

Müssen die Packages im gleichen Projekt wie die Hauptanwendung liegen, oder sollte ich die lieber in eigenen Projekten kompiliert werden?

Ich erhalte immer noch diese verflixte Meldung, dass ein Package bereits in 2 anderen importiert wurde, obwohl ich wirklich NIRGENDS (weder uses noch requires) dieses problematische Package angegeben habe. Es kann also gar keinen Querverweis geben.

tyler