DLL Problem mit XE7

[himitsu]

FreeLibrary ... siehe mein Vorredner.



Versuch mal tparameter = packed record und wenn die DLL Strings rausgibt, dann hoffe ich die werden nicht bei Prozedurende freigegeben.

Die VCL in einer DLL ist aber keine sonderlich gute Idee und kann natülich auch manchmal Probleme bereiten (außer vielleicht in einem eigenem Thread laufend), denn wenn man z.B. mal in TApplication.ProcessMessage reinsieht, dann erkennt man, daß dann Einiges an Funktionalität fehlt, bzw. Schief laufen kann, wenn die Messages nicht im eigenem Modul verarbeitet werden.

[helste]

Ja, freelibrary war ein Copy and paste Fehler.

In meiner realen Anwendung verwende ich das gar nicht, weil ich da die DLL statisch eingebunden habe. Hat einfach weniger Probleme geliefert.

In meinem Beispielprogramm habe ich nun freelibrary korrigiert. Merkwürdigerweise liefert nun auch Button1 in der Maske der dll DAS Problem. Also sobald eine Datenbankfunktion ausgeführt wird, bekomme ich Probleme beim Freigeben der DLL.
Das Programm hängt dann einfach beim Betätigen von Button3 im rufenden Programm.

Was VCL anbelangt, so muss ich das leider machen. Ich bin gerade dabei ein Programm mit hundertausenden Programmzeilen umzubauen. Da wird eine Maske nach der anderen und ein Modul nach dem anderen auf die neue Benutzeroberfläche gebracht. Das geht leider nur über die DLL.

Hat bisher auch noch kein Problem gegeben, bis ich jetzt auf XE 7 umgestiegen bin.

Ich habe jetzt aber einen anderen Verdacht. Nachdem das immer im Zusammenhang mit den IBDAC Komponenten auftritt, kann da natürlich auch die Ursache liegen. Ich musste da auf die neueste Version updaten, um sie für XE7 nutzen zu können.
In delphi XE5 habe ich noch die alte Version der IBDAC. Ob da nicht auch mit Delphi XE5 das Problem auftritt. Ich trau mich aber nicht da ein Update zu machen, weil ich sonst keine Chance mehr habe die DLL neu zu kompilieren, wenn das Problem da auch auftritt.

Werde aber mal mit Devart Kontakt aufnehmen. Mal sehen, ob die eine Erklährung haben.

Vorher versuche ich noch eine Routine zu erstellen, wo keine VCL benutzt wird, sondern nur ein reiner Datenbankaufruf geschieht. Mal sehen, ob da das Problem auch auftritt.

Echt doof so was. Da macht man nur ein Update auf die aktuellsten Versionen und schon sitzt man in der Sch....

[helste]

Hab's gerade mal ausprobiert. Liegt irgendwo bei IBDAC.
Habe eine Procedure geschrieben, die eine Datenbankverbindung erstellt, einen Datenbankaufruf macht und den Inhalt eines Feldwertes in eine Stringliste stellt und diese dann in eine Textdatei schreibt. Läuft alles planmäßig ab, aber beim Freigeben der DLL hängt die Anwendung dann.
Ob das nun an Delphi XE7 hängt oder an der aktuellsten Version von IBDAC weiß ich aber nicht. Eventuell mach ich noch mal Delphi XE5 mit neuester IBDAC auf einen Testrechner drauf.

Werde jetzt mal bei Devart nachfragen, möchte mich aber bei allen bedanken, die sich hier eingebracht haben. Danke Jungs.

[EWeiss]

Irgendwie eine Verbindung zum ComObjekt ?
Hatte auch letztlich ein Problem mit dem freigeben einer DLL die meine Anwendung zum hängen brachte.
Wenn ich CoUninitialize aufgerufen habe bevor die DLL freigegeben wurde hat sich mein Programm aufgehängt.

CoUninitialize nach dem freigeben der DLL hat das Problem beseitigt.

Kann nicht sehen ob deine Datenbank irgendeine Anbindung zu Com hat.
Wenn nicht dann vergess meinen Beitrag einfach.

gruss

[helste]

Hat damit nichts zu tun. Aber trotzdem Danke.

Habe mal ein kleines Testprogramm an Devart geschickt. Lässt sich zum Glück jetzt wunderbar reproduzieren.
Hoffentlich antworten die rasch.

[BadenPower]

Delphi-Quellcode:

procedure TForm1.Button3Click(Sender: TObject); // DLL freigeben
begin
  FreeLibrary(LHnd);
  edit_test := nil;  // diese Zeile
end;

Ist es möglich, dass die markierte Zeile eventuell den Fehler auslöst?

[helste]

Nein, diese Zeile ist es sicher nicht.