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

[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