Wie, wann wird eine Dll entladen

[Löcha]

Hallo,

ich habe im Forum gesucht, aber nichts wirklich zutrefendes gefunden.

in meiner DLL ist eine Form eingebunden, die Form wird erzeugt:

Code:

exports
...

begin
  FormReport := TFormReport.Create(nil);
end;

Die Form enthält Datenbankkomponenten die dynamisch erzeugt werden.
Die DLL wird von einem anderem Program geladen, und beim schliessen der Anwendung kommt eine Zugriffsverletzung.

Der Fehler tritt im Ereigniss OnDestroy des Formulars auf. (es wird die Form zuerst freigegeben oder was anderes läuft da verkehrt) Ich kann mir den Fehler nicht so wirklich erklären, da ich nicht so viel mit DLLs zu tun hatte.

Danke im Voraus!

[edit=r_kerber]Doppelpost gelöscht! Mfg, r_kerber[/edit]

[Robert Marquardt]

ShareMem in Programm und DLL eingebunden?

Forms in DLLs ist und bleibt Unsinn, auch wenn viele Leute es trotzdem machen.

[Löcha]

ShareMem habe ich in die Dll eingebunden, ich weiss nicht ob ShareMem in die Anwendung eingebunden werden soll.

Ich habe mein Problem anders umgangen, ich habe eine Procedure geschrieben:

Delphi-Quellcode:

if Form <> nil then
  FreeAndNil(Form);

Diese Prozedur wird im OnClose Ereignis der Anwendung aufgerufen, die Zugriffsverletzung kommt nicht mehr.

Trotzdem möchte ich wissen, wie man es besser (richtig) machen kann.

[Bernhard Geyer]

Zitat von Löcha:

Delphi-Quellcode:

if Form <> nil then
  FreeAndNil(Form);

Die erste Zeile kannst Du dir Sparen: Im FreeAnNil wird die Free-Methode aufgerufen und die macht so eine abprüfung.

Zitat von Löcha:

Trotzdem möchte ich wissen, wie man es besser (richtig) machen kann.

Dazu musst Du uns etwas Code mehr Code posten (vor allem die Fehlerversion) um zu wissen wann Du die Form anlegst und wieder freigiebst.

Zitat von Robert Marquardt:

Forms in DLLs ist und bleibt Unsinn, auch wenn viele Leute es trotzdem machen.

Also ich sehe keine Alternative zu Forms in DLL's. Ist bei uns nötig um sogenannte Plugins zu schreiben. Programmteile die nicht jeder Kunde hat, aber auch Oberfläche besitzen. Welche Alternative würdest Du dafür den Vorschlagen?

[Robert Marquardt]

Ein Plugin mit Oberflaeche ist von vorneherein problematisch.
Wenn dann ueber Packages, da dort die DLL Probleme abgefangen werden.
Alternativ ActiveX.

ShareMem muss in Programm und DLL eingebunden werden.

[Bernhard Geyer]

Zitat von Robert Marquardt:

Ein Plugin mit Oberflaeche ist von vorneherein problematisch.
Wenn dann ueber Packages, da dort die DLL Probleme abgefangen werden.
Alternativ ActiveX.

ActiveX ist keine Alternative (Programm muss auch ohne Registrierung/Adminrechte laufen
Und Packages hatt auch diverse Nachteile (Exe wird aktualisiert, jedoch DLL's bleiben in alter Version vorhanden. Wird mit Package-Konzept nicht gehen, da vermutlich alle Teile mit gleicher Compiler-Version erstellt werden muss.
Und es sollte auch möglich sein Nicht-Delphi-Programme darüber einzubinden.

Zitat von Robert Marquardt:

ShareMem muss in Programm und DLL eingebunden werden.

Bei uns nicht. Die DLL-Schnittstelle ist komplett PChar-Basierend.

[franktron]

Zitat von Robert Marquardt:

Ein Plugin mit Oberflaeche ist von vorneherein problematisch.
Wenn dann ueber Packages, da dort die DLL Probleme abgefangen werden.
Alternativ ActiveX.

ShareMem muss in Programm und DLL eingebunden werden.

Apropro Packages gibts da irgend wo eine vernüftige anleitung wie man mit Packages ein Plugin machen kann.
(am besten gleich mit DB anschluss)

[roderich]

stimme Bernhard zu.
DLL's mit Formularen machen durchaus Sinn. Wir erstellen auch Plugins und andere Module in DLL's mit Oberfläche.

Die AV beim Programmende ist auch bei uns aufgetreten, wir haben es so gelöst, daß es z.B. neben InitPlugin auch eine Funktion ExitPlugin gibt, welche das Formular in der DLL schließt. Dieses ExitPlugin wird am Programmende aufgerufen.

Packages sind für mich ein komplett proprietäres Konzept und kommen daher nicht in Frage (unsere Kunden sollen eigene Plugin-DLL's mit anderen Compilern machen können), mal abgesehen von den unsäglichen Versionskonflikten.

Roderich