Formular-DLL ohne aktivierte Laufzeitkomponenten einbinden
-
Hallo,
ich habe mir eine DLL geschrieben, die ein Formular enthält, welches auf Komponenten des Hauptprojekts zugreift.
Z.B. kann ich im Hauptformular ein Panel anklicken und kann dann in meinem DLL-Formular die Caption dieses Panels ändern.
Damit kann ich mein Hauptformular ohne SPS-Anbindung mit plausiblen Daten füllen, um beispielsweise Screenshots für die Softwarebeschreibung zu erstellen.
In der DLL gibt es ein Event "OnMessage", welches das klicken abfängt und die unter dem Mauszeiger befindliche Komponente ermittelt.
Das funktioniert alles einwandfrei, solange ich in den Projektoptionen "Laufzeit-Packages verwenden" aktiviert habe. Deaktiviere ich die Laufzeit-Packages, wird das "OnMessage" des DLL-Formulars nicht mehr ausgeführt und somit bekommt die Anwendung auch das Klicken nicht mehr mit.
Durch Ausprobieren habe ich jetzt ermittelt, dass es sich um das Standard-Laufzeitpackage "vcl" handelt.
Ich möchte aber die Laufzeitpackages nicht nutzen. Als Entwurfszeitpackage läßt sich die vcl100.bpl aber nicht einbinden, da sie bereits verlinkt sei.
Wenn sie korrekt verlinkt wäre, dürfte aber eigentlich das Problem nicht da sein, oder?
-
CHLINDE schrieb:
ich habe mir eine DLL geschrieben, die ein Formular enthält, welches auf Komponenten des Hauptprojekts zugreift.
Dann mußt du sowohl DLL als auch EXE mit Laufzeitpackages linken. Punktum.
-
Das ist ja genau das, was ich nicht möchte. Weder die DLL noch die EXE sollen mit LZ-Komponenten erzeugt werden, da ich ausschließlich die exe und die DLL auf einen anderen Rechner kopieren möchte, auf dem kein C++ Builder installiert ist.
Mit LZ-Komponenten bekomme ich dann nat. nur Fehlermeldungen beim Starten.
Ich probiere es weiter...
-
Um mit Laufzeitkomponenten das Programm auf einem anderen Rechner laufen zu lassen ist keine installation der IDE notwendig, sondern es müssen nur die entsprechenden Packages installiert/kopiert sein.
Bei den Laufzeitkomponenten solltest du rtl und vcl angeben und dann diese Packages (rtl.bpl, vcl.bpl, eventuell auch die *.jdbg sowie *.de) in einem Pfad ablegen welcher durch die PATH Umgebungsvariable gefunden wird.
Anschließend sollte dein Programm auch auf dem Rechner ohne IDE laufen.MfG Stephan
-
Ja, das weiß ich, aber das ließe sich ja durch die Compilierung ohne LZ-Komponenten verhindern.
Aus meiner Sicht kann es nicht sein, dass der Builder die exe und die DLL ohne aktivierte Laufzeitkomponenten ohne jeglichen Fehler erzeugt, dann aber bestimmte Funktionen, wie in meinem Fall das Abfangen des OnMessage-Ereignisses nicht mehr ausführt.
-
audacia schrieb:
Dann mußt du sowohl DLL als auch EXE mit Laufzeitpackages linken. Punktum.
Wenn ich audacia richtig verstehe ist es aber so, und es gibt wohl auch keine andere Möglichkeit außer Laufzeitpackages.
Jedoch ich denke audacia wird sich dazu nochmals äußern.
-
CHLINDE schrieb:
Das ist ja genau das, was ich nicht möchte.
Das hilft dir leider nichts
CHLINDE schrieb:
Weder die DLL noch die EXE sollen mit LZ-Komponenten erzeugt werden, da ich ausschließlich die exe und die DLL auf einen anderen Rechner kopieren möchte, auf dem kein C++ Builder installiert ist.
Dann kopierst du eben noch rtl*.bpl und vcl*.bpl mit. Was ist das Problem?
CHLINDE schrieb:
Aus meiner Sicht kann es nicht sein, dass der Builder die exe und die DLL ohne aktivierte Laufzeitkomponenten ohne jeglichen Fehler erzeugt, dann aber bestimmte Funktionen, wie in meinem Fall das Abfangen des OnMessage-Ereignisses nicht mehr ausführt.
Hey, it compiles, ship it?
Freilich kann das sein. Nur weil es kompiliert, heißt es noch lange nicht, daß es auch richtig ist. Wie sollte der Compiler den Fehler auch bemerken; dafür ist er nicht zuständig.
Stephan schrieb:
Wenn ich audacia richtig verstehe ist es aber so, und es gibt wohl auch keine andere Möglichkeit außer Laufzeitpackages.
So ist es.
Es gibt andere Wege der modulübergreifenden Kommunikation wie z.B. COM, die auch ohne Laufzeitpackages funktionieren, aber wenn du direkt auf C++- oder Delphi-Klassen aus einem anderen Modul zugreifen willst, mußt du beide Module mit denselben Laufzeitpackages linken. Wenn du das nicht tust, handelst du dir eine Reihe von Problemen ein, von denen diejenigen, auf die du gerade gestoßen bist, noch die kleinsten sind.
-
Ich habe es jetzt zusammen mit meinem Kollegen hinbekommen.
Das Problem war, dass die DLL ihr eigenes OnMessage-Event für das Formular innerhalb der DLL ausführt.
Klicke ich jetzt auf eine Komponente innerhalb der Hauptanwendung, bekommt das die DLL nicht mit.
Jetzt übergebe ich beim FormShow() der DLL eine Referenz auf das OnMessage der Hauptanwendung und so bekommt das die DLL mit und ermittelt das Control aus der Hauptanwendung heraus.
So kann ich die Eigenschaften des Controls der Hauptanwwengung aus dem DLL-Form heraus verändern.Warum das Ganze nur bei Kompilierungen ohne Laufzeitkomponenten notwendig ist, bleibt mir ein Rätsel.
-
Weil durch Deaktivieren der Runtimekomponenten für die DLL und das Hauptprogramm jeweils eine eigene Version der Runtimekomponenten erstellt wird. Nämlich in DLL und der EXE. Mit externen Runtimekomponenten läd das Hauptprogramm diese aus den BPLs einmal. Die eigentliche DLL will auch die Runtimekomponenten aus den BPLs laden. Windows erkennt aber, dass diese BPLs schon geladen sind und übergibt der DLL Referenzen auf diese. Beide benutzen nun die selben Runtimekomponenten.
So wie Du es jetzt gemacht hast, mag es funktionieren. Kann dir aber Speicherlecks und auch Race-Conditions verursachen, wenn Du nicht besonders beim Programmieren aufpasst. Und so wie ich deine Beiträge interpretiere, weisst Du vermutlich gar nicht auf was Du achten müsstest.
-
CHLINDE schrieb:
Ich habe es jetzt zusammen mit meinem Kollegen hinbekommen.
Ja, es war eigentlich nur eine Frage der Zeit.
CHLINDE schrieb:
Warum das Ganze nur bei Kompilierungen ohne Laufzeitkomponenten notwendig ist, bleibt mir ein Rätsel.
Morle hat's schon angerissen.
Ich darf das nochmal wiederholen, weil es wichtig ist und du es geflissentlich übersehen hast: Nur weil etwas im Moment funktioniert, heißt das noch lange nicht, daß es auch richtig wäre. Aber suum cuique; in diesem Sinne wünsche ich dir viel Vergnügen mit den Konsequenzen