Problem mit GetClass in stat. App bei dyn. geladenen Package

[MaBuSE]

Hallo zusammen,
ich habe folgendes Problem:

Ich möchte gerne aus einer Delphi-Applikation (die keine Runtime-Package (VCL, RTL, ...) verwendet) ein einzelnes Package dynamisch laden und auf eine enthaltene Klasse zugreifen, die dann im Kontext der Anwendung laufen soll.

Wenn ich die Anwendung auf das Benutzen von dynamischen Package konfiguriere, dann klappt der GetClass Aufruf.
Dann ist meine Applikation aber klein und verwendet die Standard Package.
Ich möchte aber eine Stand-alone-Exe haben, die bei Bedarf nur auf einem Package etwas nachladen soll.

Beisp Package: (der Einfachheit-halber nur ein Formular)

Delphi-Quellcode:

package myPackage;
...
contains
  u_frmPackage in 'u_frmPackage.pas' {frmPackage};
end.

Delphi-Quellcode:

unit u_frmPackage;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TfrmPackage = class(TForm)
    Memo1: TMemo;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

implementation

{$R *.dfm}

procedure TfrmPackage.Button1Click(Sender: TObject);
var
  i: Integer;
begin
  for i := 0 to Application.ComponentCount - 1 do
  begin
    Memo1.Lines.Add(Application.Components[i].Name + ': ' + Application.Components[i].ClassName);
  end;
end;

initialization
  RegisterClasses([TfrmPackage]);
  ShowMessage('Class registered');

finalization
  UnRegisterClasses([TfrmPackage]);
  ShowMessage('Class unregistered');

end.

Die Anwendung:

Delphi-Quellcode:

u_frmApp
...
type
  TmyFormClass = class of TForm;

procedure TfrmApp.Button1Click(Sender: TObject);
var
  i: HMODULE;
  c: TmyFormClass;
  f: TForm;
begin
  i := LoadPackage('myPackage.bpl');
  c := TmyFormClass(GetClass('TfrmPackage'));
  if c = nil then
  begin
    Caption := 'Form wurde nicht gefunden';
  end
  else
  begin
    Caption := c.ClassName;
    f := c.Create(self);
    f.ShowModal;
    f.Free;
  end;
  UnLoadPackage(i);
end;
...

Wenn "Menu -> Projekt -> Optionen -> Packages -> Laufzeit Packages -> [X] LaufzeitPackages aktivieren" aktiviert ist, dann funktioniert es.

Was muß ich tun um diese Funktionalität auch zutzen zu können,
wenn "Menu -> Projekt -> Optionen -> Packages -> Laufzeit Packages -> [ ] LaufzeitPackages aktivieren" nicht aktiviert ist?

Es werden zwar die Klassen registriert (Dialog mit 'Class registered' bzw 'Class unregistered' ist zu sehen),
aber GetClass() gibt nur nil zurück.

Ich hoffe jemand heit einen guten Vorschlag ;-)

Unsere Anwendungen komplett auf Packages umzustellen geht aus verschiedenen technischen Gründen nicht.

Danke und viele Grüße
MaBuSE

:dp:

[oki]

Hallo,

ich kämpfe gerade mit dem gleichen Problem. Nachdem ich wie von MaBuSE beschrieben die Laufzeitpackages aktiviert haben klappt bei mir GetClass für die angegebene Klasse. Dabei taucht gedoch ein anderes Problem auf.

Meine Fensterklasse ist von einer eigenen Basisklasse abgeleitet. Deren Vorfahre ist TForm. Diese Basisklasse liegt wieder in einem eigenen Package.
Ich kann das Package mit meiner neuen Fensterklasse laden und auch das Fenster erstellen. Klappt soweit alles. Wenn ich jetzt aber eine Prüfung mittels is auf den Vorfahren mache liefert dies False zurück. Meine Vorfahrenklasse ist registriert (hab ich geprüft).

Hier noch mal die Hierarchie:

TMyBaseForm (liegt in BasePackage und ist mittels RegisterClass registriert)
TMySpecialForm = class(TMyBaseForm) (liegt in SpecialPackage und ist registriert)

Anwendung lädt Specialpackage mittels LoadPackage und kreiert AForm vom Typ TMySpecialForm.
Typprüfung schlägt fehl:

Delphi-Quellcode:

if AForm is TMyBaseForm then
  ....

Warum das jetzt? Ich habe andere Formulare in meiner Anwendung die auch den Vorfahren TMyBaseForm besitzen. Diese sind im Projekt der Anwendung eingebunden. Eine Prüfung auf TMyBaseForm funzt da ohne Probleme. Nur halt bei den geladenen nicht.

Gruß oki

[Bernhard Geyer]

Entweder alles Runtimepackages oder gar nichts! Mixbetrieb ist nicht möglich (bzw. nur mit sehr viel Glück und vielen harten Casts).

Hat deine Anwendung keine Runtimepackages aber die DLL schon, so ist TObject der Exe <> TObject der BPL da beide vollkommen unabhängige RTTI haben!

[Apollonius]

Ich bin ehrlich gesagt irritiert, das LoadPackage keine Exception wirft. Eigentlich sollte LoadPackage auf doppelte Units prüfen und gegebenenfalls eine Exception auslösen. Das aber selbst mit Tricks GetClass nicht funktionieren kann, ist auch klar: Letztlich schreibt RegisterClass die Klasse nur in eine globale Variable der Unit Classes. Und diese Variable ist natürlich nur über Modulgrenzen hinweg benutzbar, wenn man Laufzeitpackages verwendet.

[oki]

ok,

schon mal Dank.
Leider klemmt es jetzt etwas mit dem Verständnis des gesagten; oder besser mit der Umsetzung.

Das mit der RTTI und der Registrierung leuchtet mir ein. Die Frage ist jetzt nur, wo genau sollte ich nur mit Runtimepackages arbeiten. Reicht es in meiner Exe oder muss ich da bei meinen Packages etwas beachen?

Sorry für die platten Fragen, aber an der Stelle bin ich völlig blass. Hab halt immer meine Packages erstellt (Compiler Design/Runtime) und gut wars. Hatte nie den Bedarf Packages zur Laufzeit zu laden.

Ich fasse auch noch mal zusammen, was ich bis jetzt an welcher Stelle gemacht habe:
- Package "BasePackage" mit Compilereinstellung "Entwurf und Laufzeit" erstellt. (Ausgabeverzeichnis ...CodeGear\5.0\...)
- Package "SpecialPackage" mit Compilereinstellung "Entwurf und Laufzeit" erstellt. (Ausgabeverzeichnis ...CodeGear\5.0\...)

Meine Anwendung die SpecialPackage laden soll habe ich mit "Laufzeit-Package verwenden" aktiviert compiliert. Hier konnte ich jedoch die beiden Packages nicht mit eintragen. Kommt der Fehler "F2084 Interner Fehler: U1036" wenn meine MainForm.pas compiliert wird. Das MainForm ist ebenfalls ein Nachfahre meines BaseForms aus "BasePackage". Somit werden da die Units aus dem Package eingebunden.
Ich denke das ist vielleicht eine Folge des besagen Mischbetriebes.

Da diese Anwendung nur für den internen Gebrauch gedacht ist habe ich kein Problem mit den Laufzeitpackages. Ein sauberer Weg ist mir recht. Nur wie?

Schon mal Dank und Gruß

oki

[Apollonius]

Alle Units, die in mehreren Modulen verwendet werden, müssen in allen verwendenden Modulen mit einem Laufzeitpackage eingebunden werden. Insbesondere müssen also sowohl die Packages als auch das Hauptprogramm mit den Packages RTL und VCL kompiliert werden.

[oki]

Hi Apollonius,

das ging zu schnell. ich glaub ich brauch das grad etwas praktischer.

Bsp.:
ich habe eine Unit MyBaseWindow.pas die ich in folgenden Modulen verwende:
- BasePackage.bpl
- SpecialPackage.bpl
- MyApp.exe

in den Projektoptionen habe ich jetzt die Lasche "Beschreibung". Dort kann ich für die angegebenen Packages einmal den Schalter "Verwenden für" mit den Optionen "Entwurf", "Laufzeit" und "Entwurf und Laufzeit" einstellen. Bei allen Modulen kann ich in der Lasche "Packages" die Checkbox "Laufzeitpackages verwenden" wählen. Darüber befindet sich das ListView "Entwurfs-Packages" in der alle in meiner IDE geladenen Packages gecheckt sind.

Wo muss ich jetzt was rein und was raus nehmen.

Ich stell mich heute vielleicht etwas blöd an, aber mich drückt der Terminschuh und ich hoffe ich schaffe es heute mit euch ohne eigenes Grundlagenstudium.

Dank und Gruß oki

[Apollonius]

Jedes Package kann Units enthalten (contains), andere Units in das Package einkompilieren und mit requires andere Packages einbinden. Requires greift dabei auf die Units zu, die im anderen package unter contains aufgelistet sind.
Nun gilt die Regel: Jede Unit darf nur in einem einzigen Modul einkompiliert sein. Wenn sie in mehreren gebraucht wird, muss ein Package die Unit unter contains aufführen, welches die anderen mit requires einbinden.
Konkret heißt das bei dir: Deine Unit MyBaseWindow musst du entweder in BasePackage oder in SpecialPackage hineinkompilieren; vermutlich wirst du BasePackage wählen. Das heißt, dass du neben der normalen Auflistung in der Uses-Klausel die Unit in die Contains-Klausel schreibst. In allen anderen Packages, die die Unit verwenden, schreibst du dann BasePackage in die Requires-Klausel. Auf die Requires-Klausel hast du auch direkt im Projekt-Baum Zugriff.

Das selbe musst du dann auch für das Hauptprogramm tun. Da es dort jedoch keine Requires-Klausel gibt, musst du die Projekt-Optionen bemühen: Bei Packages die Checkbox "Laufzeitpackages verwenden" setzen und dein Package in das Edit-Feld hinzufügen.

Die selben Regeln gelten auch für alle anderen gemeinsam genutzten Units - auch die Delphi-eigenen. Daher musst du in jedem Fall das Package RTL einbinden, gegebenenfalls auch VCL.

[oki]

hab ich verstanden.

Ich teste es.

Gruß oki

[oki]

Moin,

ich habe jetzt gründlich aufgeräumt. Alle Units sind nur noch in einem Package eingebunden. In meiner Exe habe ich dann mein BasePackage in der Rubrik "Laufzeitpackage verwenden" zusammen mit "rtl" und "vcl" eingetragen und erfolgreich kompiliert. Das lief dann auch ohne die zuvor erwähnten Fehler ab.

Dafür erst mal Dank! :thumb:

Jetzt hat sich folgendes herausgestellt. Ich lade mein SpecialPackage zur Laufzeit mittels LoadPackage. Die in diesem Package registrierte Fensterklasse TMySpecialForm wird durch GetClass gefunden. Die Prüfung mit "is" ist erfolgreich. Leider werden aber alle in BasePackage definierten und registrierten Fensterklassen jetzt nicht mehr erkannt. Alle Registrierungen erfolgen in den entsprechenden Units mittels RegisterClass im initialization-Teil der Unit.
Ich habe dann in einer Unit des SpezialPackage im initialization-Teil alle Fenster des BasePackage noch einmal mittels RegisterClasses aufgenommen. Siehe da, jetzt werden sie erkannt.

Ich hatte eigentlich gehofft, dass ich durch die Einbindung des Packages BasePackage als Runtimemodule das in dem nachzuladenden Package nicht mehr tun muss. Ich habe den Hinweis zur Klassenregistrierung in der Unit Classes zwar wahrgenommen, wie das aber konkret abläuft und sich auswirkt hab ich noch nicht verstanden. Auch das Thema "Modulgrenzen" ist mir so nicht richtig klar geworden.
Im Grunde ist mein "Hauptmodul" ja meine Exe. Diese hat das Package BasePackage, angegeben als Runtimepackage, eingebunden. Damit sollte es doch alle registrierten Klassen aus BasePackage kennen. Würde meine Exe jetzt die Klasse aus dem nachgeladenen SpezialPackage nicht kennen, so könnte ich das verstehen. Aber es ist genau umgekehrt. Der Code in meiner Exe erkennt die Klassen aus dem nachgeladenen Spezialpackage, aber nicht die Klassen aus BasePackage. Für mich ist das grad mal verkehrte Welt.

Ich habe auch gerade mal eine Idee getestet. Bevor ich das SpezialPackage lade kennt meine Anwendung die registrierten Klassen. Nach dem Laden nicht mehr. Wird da vielleicht im Hintergrund das BasePackage der Exe entladen, damit das in "erforderlich" eingetragenen BasePackage des geladenen SpezialPackage verwendet wird? Da fällt mir ein, dass in den Finalization-Teil der Fensterunits auch ein UnregisterClass für die Fensterklassen aufgenommen habe.


Mal schauen, wenn einer eine Idee hat, her damit.

Und wieder Dank im Voraus,

Gruß oki

[Apollonius]

Achte doch mal beim Debuggen auf die Ereignisanzeige. Dort müsste es eigentlich Nachrichten beim Laden und Entladen von Packages geben. Den Fehler kann ich mir allerdings nicht erklären. Debug doch mal SpecialPackage und prüfe, ab wann Aufruf von RegisterClass GetClass('AlteKlasse') nil zurückgibt.

[oki]

Moin, Moin,

ich habe jetzt folgenden Zustand. Alle verwendeten Units sind jeweils nur in einem Package eingebunden. Soweit ist der Fehler U... verschwunden. Die Klassen werden auch registriert und es lässt sich ordnungsgemäß drauf zugreifen. Ein Fenster habe ich aus dem Package herausgenommen, da wurde ein externes Package verwendet. Das hatte Probleme bereitet.

Leider ist noch nicht alles im Reinen. Ich bekomme immer noch Fehlermeldungen bei der Ausführung des Programmes und die Komponenten verhalten sich im nachgeladen Package nicht so wie die Originalkomponenten. Ich durchsuche gerade meine Platte nach doppelt vorhandenen Packages. Mal schauen was das noch wird.

Erfreulich ist es nicht.

Gruß oki

[MaBuSE]

Zitat:

Zitat von Bernhard Geyer

Entweder alles Runtimepackages oder gar nichts! Mixbetrieb ist nicht möglich (bzw. nur mit sehr viel Glück und vielen harten Casts).
Hat deine Anwendung keine Runtimepackages aber die DLL schon, so ist TObject der Exe <> TObject der BPL da beide vollkommen unabhängige RTTI haben!

Ich kann dem Bernhard nur recht geben. Mixbetrieb ist definitiv nicht möglich.

Glücklicherweise hatte ich im Oktober letzten Jahres die Gelegenheit mit Barry Kelly (das ist der, der bei Codegear am Compiler arbeitet) ca. 2 Stunden allein und ungestört zu sprechen. In diesem Gespräch habe ich viele Probleme, die wir mit Delphi hatten, angesprochen und teilweise gute Lösungsansätze bekommen.
Unter anderem hatte ich ihn auch nach der Problematik mit den Packages gefragt. (Siehe 1. Beitrag)
Der Mixbetrieb ist definitiv nicht möglich.

Das liegt unter anderem daran, das die Adresstabellen anders aufgebaut sind, je nachdem ob die Anwendung mit oder ohne Runtime Packages arbeitet. Es werden beim Compilieren durch den Schalter RuntimePackages viele grundlegende interne Dinge komplett anders gemacht. Es ist also nicht "nur" die verwendeten Package in die Exe gelinkt, sondern wie schon Geschieben, es wird viel mehr gemacht. ;-)

Da meine Frage beantwortet ist, werde ich das Thema (offene Frage) als beantwortet markieren.

[oki]

Hallo MaBuSE

Dank für die Info. Da das hier dein Thread ist werde ich meine aktuellen Themen in einem neuen Tread zur Diskussion stellen. Das Thema Runtime-Package ist auch meiner Meinung nach damit geklärt. Meine aktuellen Probleme sollten damit sicher in diesem Kontext, aber an einer anderen Stelle liegen.

Dank und Gruß oki

[MaBuSE]

Zitat:

Zitat von oki

Hallo MaBuSE
Dank für die Info. Da das hier dein Thread ist werde ich meine aktuellen Themen in einem neuen Tread zur Diskussion stellen. Das Thema Runtime-Package ist auch meiner Meinung nach damit geklärt. Meine aktuellen Probleme sollten damit sicher in diesem Kontext, aber an einer anderen Stelle liegen.
Dank und Gruß oki

Nein, das ist OK.
Es geht ja um das gleiche. (Zumindest am Anfang ;-) )

[oki]

Dann werd ich gleich mal das nächste Problem zu diesem Thema schildern.

Ich habe mir im Debugger die Aufrufe meiner vererbten Klasse angesehen und festgestellt, dass da ein Versatz drin ist. Das passt schon mal zu dieser Aussage:

Zitat:

Das liegt unter anderem daran, das die Adresstabellen anders aufgebaut sind, je nachdem ob die Anwendung mit oder ohne Runtime Packages arbeitet. Es werden beim Compilieren durch den Schalter RuntimePackages viele grundlegende interne Dinge komplett anders gemacht. Es ist also nicht "nur" die verwendeten Package in die Exe gelinkt, sondern wie schon Geschieben, es wird viel mehr gemacht.

So wie es aussieht trifft das jetzt genau bei mir zu. Leider drehe ich mich da im Kreis.

Meine Anwendung die das Package laden soll besitzt Formuare aus BasePackage. Konkret auch das MainForm. Somit habe ich mein BasePackage als Design- und RuntimePackage kompiliert. Ich brauch ja die Formulare und Komponenten zum Designen meiner Anwendung. Das SpezialPackage ist als Runtimepackage kompiliert und enthält ein speziellen Formular als Nachfahre eines Forms aus BasePackage. Diese SpezialPackage soll dann von meiner Anwendung zur Laufzeit nachgeladen werden.
Jetzt habe ich den Verdacht, dass meine Anwendung ja das BasePackage als Designtime-Package verwendet, obwohl ich Laufzeitpackages verwenden ausgewählt und mein BasePackage mit eingetragen habe. Wird mein SpezialPackage als Laufzeitpackage geladen, welches natürlich auch BasePackage beinhaltet, so habe ich wieder den Mischbetrieb.
Dahinter kann ich aktuell keine rechte Logik erkennen, aber die Erscheinungen lassen sich für mich mit dem gesagten erst mal nur so erklären.

Meine erste Frage ist,
Liege ich damit richtig?

Meine zweite Frage
Welche Alternative habe ich?

Gruß oki

[schöni]

Hallo,

Aaaalso ich würde mit dem Verständnis, das ich beim Lesen dieses Threads gewonnen habe, das Design so abändern, das diejenigen Teile, die zum Designen der Anwendung unbedingt als Designpackage vorliegen müssen, als Designpackage übersetzt werden, während diejenigen Teile, die erst zur Laufzeit nachgeladen werden oder eben während des Entwurfsprozesses, konsequent als Laufzeitpackage übersetzt werden. Gemeinsam benötigte Tele ghören dann in eine gewöhnliche Unit, die von beiden Teilen verwendet wird.

[MaBuSE]

• Wenn "keine Laufzeitpackages" beim Kompilieren ausgewählt ist, passiert Folgendes:
  
  Dem Compiler sind alle Packages egal.
  
  Bei einem Build: (Projekt erzeugen)
  Es werden einfach alle *.pas Dateien kompiliert, die in der uses Anweisung des Programms (*.dpr) und der einzelnen Units (*.pas) angegeben sind kompiliert und dann die entsprechende *.dcu eingebunden (gelinkt). Wenn keine *.pas Datei vorhanden ist, wird direkt die entsprechende *.dcu eingebunden.
  
  -> Es entsteht eine Exe Datei, die alles eingebunden hat und keine Packages braucht.
  
  Du benötigst zum Kompilieren:
  • Deine Projektdateien (*.dpr, *.pas, *.dfm, *.res)
  • alle von Dir verwendeten *.dcu Dateien der VCL, Komponenten, ... (z.B. aus "$(DELPHI)\lib")
  Du benötigst zum Starten des Projekts:
  • Deine Exe Datei
• Wenn „mit Laufzeitpackages“ beim Kompilieren ausgewählt ist, passiert Folgendes:
  
  Es wird vor dem Kompilieren der *.pas Dateien geschaut, ob diese in einem Package enthalten sind. Wenn ja, dann wird die *.dcu nicht eingebunden, sondern auf as Package verwiesen.
  Es werden also nur die *.pas Dateien kompiliert und *.dcu Dateien eingebunden, die in keinem Package enthalten sind. Also die, die zum Projekt gehören.
  
  Um die Anwendung starten zu können, sollten dann alle statisch verlinkten Runtime-Packages vorhanden sein.
  Natürlich werden auch alle Packages, die in dem requires Abschnitt verwendeten Packages aufgelistet sind, benötigt.
  
  DesignTime Packages werden zum Kompilieren nicht benötigt, sie enthalten "nur" den Code, der von der IDE benötigt wird um während der DesignTime (also der Programmerstellung in der IDE) ausgeführt zu werden.
  (Zum Beispiel Property-Editoren und Component-Editoren, Wizards, IDE-Plugins, ...)
  
  Du benötigst zum Kompilieren:
  • Deine Projektdateien (*.dpr, *.pas, *.dfm, *.res)
  • Packagedateien (*.dcp)
  • alle von Dir verwendeten *.dcu Dateien, die nicht in einem Package stecken.
  Du benötigst zum Starten des Projekts:
  • Deine Exe Datei
  • alle verwendeten Packagedateien (*.bpl)
  Ein Sonderfall ist ein Package, dort werden zum Kompilieren noch nicht mal die *.dcu Dateien der in requires angegebenen Package benötigt, es reicht die *.dcp Datei, in der alle relevanten Informationen der dcu's enthalten sind. Wichtig bei DesignTime Packages, zu denen die *.dcu fehlen. (z.B. Proxy.dcu)
  
  siehe auch Lösung: Das leidige Problem mit der DsgnIntf bzw. Proxy.dcu

Ich hoffe die Infos helfen Dir.

[oki]

Hallo MaBuSE,

herzlichen Dank für die Erläuterungen. Damit bin ich mir dann sicher, dass meine Exe nur mit Laufzeitpackages arbeitet und der Fehler an der Stelle nicht sein kann. Somit macht es Sinn hier weiter zu suchen, da der Fehler offensichtlich an einer anderen Stelle liegt.

@schöni: Das ist so nicht möglich. Aber mit den Erläuterungen von MaBuSE ist das dann auch nicht nötig, da es alleine auf die konsequente Verwendung der Runtimepackages ankommt. Ich denke, der einzige Fehler der hier passieren kann ist dann nur der Fall, dass man die Exe ohne Runtimepackage verwenden compiliert und dann eins nachlädt. Habe ich den Schalter "Laufzeit-Packages verwenden" gewählt, so kann eigentlich nichts mehr schief gehen.

Ich suche weiter! (ist ja bald Ostern :mrgreen: )

Dank und Gruß oki