BPL zusammenfassen ?

[hanspeter]

Hallo,
ich bin gerade am Redesign eines größeren Projektes.
Bisher alles in einer Exe.

Die EXE überschreitet inzwischen 10 MByte (gezippt 4 MByte).

Das Programm läuft zu Sportveranstaltungen, da ist öfters mal eine Korrektur notwendig, die
Sonntags und sofort erfolgen muß. Die Übertragung über Internet ist bei der Größe dann ein wesentlicher Zeitfaktor.
(Übertragung maximal ISDN)
Ich habe jetzt mit BPL und DLL experimentiert.
Hier weis ich, wie es mit beiden Möglichkeiten geht.
DLL ist keine richtige Lösung. Unabhängig von der Tatsache, dass Delphi mit DLL design bedingt Probleme hat, habe ich
gemerkt, dass z.B. eine dll mit einem Formular 5 Editfelder und 1 Button) bei Verwendung von IBObjects 1,2 MByte groß wird.

Bei BPL habe ich mir zum Probieren einen Delphi-freien Rechner installiert und war richtig erschrocken, dass fast
200 BPL benötigt werden.
Jetzt habe ich so ein bischen Bedenken, ob ich mit Laufzeitpackages mir eine BPL Hölle an Land ziehe.
Ein geändertes BPL versehentlich nicht mit ausgeliefert und das Problem ist da.

Alleine IBObjects kommt mit 18 BPL daher.

Ich habe bereits mit einem Com-Server experimentiert, hat mich aber auch nicht so glücklich gemacht.

Meine Frage jetzt:
Gibt es Tools, welche mir eine BPL Abhängigkeit listen.
Das Programm benötigt nachfolgende BPL...

Gibt es ein Tool welches mir zeitliche Abhängigkeiten listet und vereinfacht.
Letztes Update des Anwenders am ... nachfolgende BPL wurden geändert.
Manche BPL sind relativ klein.
Da ich von diesen in der Regel den Quellcode habe, macht es Sinn solche Bibliotheken in einer zusammenzufassen.
(z.B. alle IBObjets runtime Bibliotheken in einer).

Gruß
Peter

[RavenIV]

wir haben gute Erfahrungen mit DLLs gemacht.
Unsere Software hat eine exe und 28 DLLs, gesamt 57 MB an ausführbarem Code.
Immer alles übertragen wäre für uns nicht machbar.

Wenn man nicht die units wild quer-einfügt (in den uses), braucht man bei Änderungen nur die geänderte DLL übertragen.
Wenn sich natürlich die Schnittstelle / Aufruf ändert, dann halt alle betroffenen Programmteile.

[neuronet]

Gebe RavenIV recht.

Wenn Du hausgemachte (also von Delphi erstellte) DLLs verwendest, sollte es überhaupt keine Probleme geben.

Ich verwende auch DLLs um bei Updates nicht gleich alles über's Netz schicken zu müssen, und es funzt einwandfrei.

[dfried]

Man muss allerdings dazusagen, dass es mit Formularen in der DLL nicht ganz so einfach ist wenn das Programm MDI ist! Dann Funktioniert nämlich die TA-Taste in den Formularen aus der DLL nicht.

[Igotcha]

Zitat von dfried:

Man muss allerdings dazusagen, dass es mit Formularen in der DLL nicht ganz so einfach ist wenn das Programm MDI ist! Dann Funktioniert nämlich die TA-Taste in den Formularen aus der DLL nicht.

Nicht nur das, die gesamte "gewohnte" Fensterbedienung spielt nicht mit der MainApp zusammen, da das aus einer DLL erzeugte MDI-Child nicht das gemeinsame Application-Objekt besitzt, wie die Hauptanwendung.

Bin vor 1 1/2 Jahren selbst über dieses Problem gestolpert, habe mich daraufhin in BPLs eingearbeitet und meine Anwendung mit BPLs aufgebaut.

Es gibt bei mir einige "Core"-BPLs, die für das Gesamtsystem zuständig sind und dann "Lösungen" in Form von BPLs. Ändere ich nun etwas an einem Lösungsmodul, muss nur dieses Upgedated werden - ändert man natürlich etwas am Systemkern, muss man die entsprechede Core-BPL und selbstverständlich die darauf aufbauenden Lösungs-BPLs neu kompilieren und verteilen.

Für die Verteilung habe ich einen "Launcher" entwickelt, über den meine Anwendung gestartet wird. Abhängig vom User und seinen Zugriffsrechten auf bestimmte Lösungsmodule ermittelt dieser die benötigten Dateien auf den Zielrechnen und kopiert diese vom Quellserver, sofern sie gar nicht existiert, bzw. updated sie, sofern dort eine neue Version liegt.

Durch diese Methode ist es mir möglich, die Gesamtanwendung, die ca. 22 MB besitzt bei einer Installation auf 1 MB zu reduzieren und zudem noch benutzerfreundlich zu gestalten. Der Endanwender führt das Setup aus, der Launcher wird installiert, schaut nach "Oh, gar nix da" und kopiert automatisch die benötigten Dateien auf das Zielsystem.

Gruß Igotcha

[dfried]

Zitat von Igotcha:

Nicht nur das, die gesamte "gewohnte" Fensterbedienung spielt nicht mit der MainApp zusammen, da das aus einer DLL erzeugte MDI-Child nicht das gemeinsame Application-Objekt besitzt, wie die Hauptanwendung.

Das kriegt man noch gebacken (hab mich auch länger damit beschäftigt), aber das mit den Tabs geht einfach nicht, da helfen nur BPL's oder Delphi 4 (Da ging das nämlich noch wunderbar!)

[hanspeter]

Zitat von dfried:

Man muss allerdings dazusagen, dass es mit Formularen in der DLL nicht ganz so einfach ist wenn das Programm MDI ist! Dann Funktioniert nämlich die TA-Taste in den Formularen aus der DLL nicht.

Ja da habe ich wohl ein Problem.
Das Hauptformular ist ein MDI.
Zwischen Hauptformular und einem Childform gebt es praktisch keine Interaktion. Dem Fenster wird ein Parameter z.B. Startnummer
übergeben.
Ich überlege schon ein Design so ählich wie bis Delphi 7. Eine Menüliste am oberen Bildschirmrand und dann alle Fenster nicht MDI darunter.

Gruß
Peter

[jbg]

Zitat von hanspeter:

Bei BPL habe ich mir zum Probieren einen Delphi-freien Rechner installiert und war richtig erschrocken, dass fast 200 BPL benötigt werden. [...]
Alleine IBObjects kommt mit 18 BPL daher.

Du kannst die benötigten IBObjects Units in ein eigenes Package packen und hast somit die 18 BPLs auf eines reduziert. So mache ich das immer mit der VCL und RTL, wenn das Programm nicht überragend groß werden soll, aber Plugins unterstützt.
Das gibt es dann halt ein Package Core mit

Delphi-Quellcode:

contains
  Windows,
  SysUtils,
  Classes,
  Contrns,
  StrUtils,
  Forms,
  Controls,
  Graphics,
  StdCtrls,
  ...

Die Liste ist recht schnell aufgebaut, da Delphi im Dialog, der einem zeigt, dass das VCL oder RTL Package eingebunden werden muss, über die Details die benötigten Units in einer Kommaliste anzeigt.

[Sherlock]

Vorab: D2007

Ich würde gerne das Thema nochmal aufgreifen, da ich gerade mit Packages ein wenig experimentiere.
Ich habe jetzt nachdem ich viele Fehlermeldungen "weggegoogelt" habe, ein OCX mit Laufzeit Packages erzeugt. Stehe aber nun vor dem trivialen Problem die BPLs zu identifizieren, die der EXE (in meinem Fall dem OCX) mitgegeben werden müssen. Es wird einem nicht wirklich leicht gemacht, denn die Units "windows" oder meinetwegen "sysutils" gibt es nicht als BPL, zumindest finde ich sie nicht. Ich finde nur einen riesen Stapel an BPL unter "C:\Program Files (x86)\CodeGear\RAD Studio\5.0\bin" deren Benennung nur entfernt an die "benötigten" Units erinnern. Meist haben die dann aber noch sowas wie "ide" im Dateinamen, was mich wieder von der Verwendung abschreckt.

Um die Frage des TE aufzugreifen: Gibt es ein Tool, das mir deutlich sagt: "Diese Datei von diesem Ort muss mitgegeben werden"?

Edith sagt: Sackzement! Hab die BPLs gefunden. Windows\SysWOW64\ muss man auch erstmal drauf kommen. Bleibt noch das Problem, daß ich ungern alle mitgeben will, sondern nur die wirklich nötigen.

Sherlock

[mkinzler]

Du kannst natürlich ein neues Package erzeugen und die dcp dort einfügen