Hallo alle zusammen,
vielen, vielen Dank für die Fülle an Infos und Erläuterungen. Ich versuche mal in einem einzigen Post noch zusätzlich Infos zu meinem Fall zu geben. Ich hoffe, ich vergesse nichts
Es wurde nach dem Stacktrace gefragt, den ich gerne hier an den Post ran hänge. Und zwar tue ich das in Form des Bugreports, den ich von madExcept bekommen habe. Ich hab mal diejenigen Infos entfernt, die meiner Meinung nach nicht relevant bzw. benutzerbezogen sind und daher nicht unbedingt ins WWW müssen
Zur Erläuertung: die Applikation, die die
DLL einbindet, trägt den namen "edmWarml.exe". Die
DLL selbst hat den Namen "DynSearchDialog.dll". In dieser
DLL wird ein Formular (TForm) erzeugt (Name "DynamicSearchDialog") und hierin gibt es wiederum die Prozedur "LoadIni". Und genau dort erstelle ich dann das
TIniFile Objekt, arbeite damit und gebe es wieder frei; exakt so, wie ich es im ersten Post beschrieben habe.
Auch wurde an anderer Stelle gefragt, ob es globale Variablen etc. gibt, ich denke, das sollte ich hier auch gleich erwähnen: nein! Das TForm-Objekt existiert übrigens nur innerhalb der
DLL und da wird nichts nach außen gegeben. Sämtliche Zugriffe auf "public" Methoden des TForm-Objekts erfolgen durch entsprechend exportierte Methoden der
DLL. Und auch sonst arbeite ich nicht mit globalen Variablen
wo es sich vermeiden lässt (ist ja nicht überall möglich, leider). Das TIniFile-Objekt existiert auch nur im Kontext der Prozedur
LoadIni. Also dass da an anderer Stelle des Projekts/Codes Speicher verbogen wird, halte ich doch für sehr unwahrscheinlich. Das Objekt hat nur ein sehr, sehr kurzes Leben
Und meine
DLL exportiert keinerlei managed types: weder String, noch Array, noch irgendwelche Objekte. Alles ist als CDECL deklariert und wie gesagt: das IniFile-Objekt ist auch nichts, was in einer direkten
DLL-Methode steht.