Zugriffsverletzung beim Zerstören der TIniFile-Instanz

[freimatz]

Hallo,
ich weiss jetzt nicht ob ich konkret weiterhelfen kann. Was ich bei so Problemen und wenn Konstruktoren oder Destruktoren fehlen mache: leite doch von TIniFile eine neue Klasse ab und verwende diese. Füge der Klasse jeweils ein Create und Destroy hinzu (mit inherited) und setze einen Breakpoint darauf. Manchmal kam es schon vor, dass man schon früher im Destroy vorbei kam als erwartet. Das spätere Free "knallt" dann zu recht.

[TheSledgeHammer]

Zitat von freimatz:

Hallo,
ich weiss jetzt nicht ob ich konkret weiterhelfen kann. Was ich bei so Problemen und wenn Konstruktoren oder Destruktoren fehlen mache: leite doch von TIniFile eine neue Klasse ab und verwende diese. Füge der Klasse jeweils ein Create und Destroy hinzu (mit inherited) und setze einen Breakpoint darauf. Manchmal kam es schon vor, dass man schon früher im Destroy vorbei kam als erwartet. Das spätere Free "knallt" dann zu recht.

Aus genau solchen Gründen hab ich mir angewöhnt, Variablen explizit auf NIL zu setzen und im Finally-Block nochmals explizit auf NIL zu prüfen. Die Ini-File-Instanz per se ist nicht das Problem hier. Eher, dass es innerhalb der DLL aufgerufen wird. Wir verwenden System.IniFiles an zig verschiedenen Stellen und noch nie kam es zu einem Fehler dieser Art. Die TForm-Komponente, die jetzt in der DLL ausgelagert ist, war früher in die Applikation mit rein kompiliert. Und in dieser Konstellation hat das jahrelang einwandfrei funktioniert.

[hoika]

Hallo,

Zitat:

131b0573 +12f DynSearchDialog.dll DynamicSearchDialog 602 +29 TFormDynamicSearchDialog.LoadIni

also Zeile 602 in der Unit DynamicSearchDialog.
steht da wirklich das IniFile.Free?


Nun zum Ausklammern:
1. LoadIni: Code komplett ausklammern (erste Zeile ein Exit?)
2. InitSearch: Aufruf von LoadIni ausklammern

[TheSledgeHammer]

Ja, in der Zeile 602 steht exakt das Ich hab es auch als Screenshot mal anbei mit geschickt.

Also wenn ich den Code ausklammere, dann wird auch kein Fehler kommen. Ich versteh den Sinn an der Stelle nicht so ganz. Ich mein: was ich nicht aufrufe, macht auch keine Probleme, oder? Was soll denn an der Stelle der Nutzen sein, würdest du mir das mal erläutern?

[Blup]

1.
Wenn Strings zwischen DLL und Anwendung übergeben werden, muss in beiden ShareMem eingetragen und die "ShareMem.dll" mitgeliefert werden.

Alternativ kann man WideString für Parameter und Rückgabewerte verwenden (auch in Records) z.B.
function MyFunctionDDL(AParam: WideString): WideString; stdcall; Die Speicherwaltung für diese Strings erfolgt automatich durch OleAuth32, die zu Windows gehört.

2.
Wenn in der DLL TForm verwendet wird, enthält die DLL eine komplett eigenständige Kopie der VCL.
Die VCL verwendet ebenfalls globale Variablen, insbesondere "Application".
"Application.Handle" muss vor der Verwendung der VCL in der DLL einmalig gesetzt werden.

Delphi-Quellcode:

{in der DLL, Handle der Anwendung übernehmen}
procedure InitVCL(AHandle: THandle); stdcall;
begin
  Application.Handle := AHandle;
end;
{in der Anwendung, Handle der Anwendung übergeben}
...
InitVCL(Application.Handle);

3.
Der Bugreport zeigt, ShowModal wird rekursiv noch einmal aus LoadIni über ProcessMessages aufgerufen.
Das ist an sich schon nicht zulässig.
Es scheint aber auch das "iniFile" keine lokale Variable der Methode LoadIni ist, wie es eigentlich sein sollte.

[TheSledgeHammer]

Zitat von Blup:

2.
Wenn in der DLL TForm verwendet wird, enthält die DLL eine komplett eigenständige Kopie der VCL.
Die VCL verwendet ebenfalls globale Variablen, insbesondere "Application".
"Application.Handle" muss vor der Verwendung der VCL in der DLL einmalig gesetzt werden.

Delphi-Quellcode:

{in der DLL, Handle der Anwendung übernehmen}
procedure InitVCL(AHandle: THandle); stdcall;
begin
  Application.Handle := AHandle;
end;
{in der Anwendung, Handle der Anwendung übergeben}
...
InitVCL(Application.Handle);

Ich hab mir das mal zu Gemüte geführt. Hab das meiner Meinung nach auch korrekt umgesetzt, allerdings kommt jetzt irgendwann im Erstellungsprozess die Exception
Exception-Klasse EOSError mit Meldung
System Error. Code 1400. Ungültiges Fensterhandle.

Application war auch zu Beginn nicht verfügbar, da die Unit Vcl.Forms nicht eingebunden war. Ich möchte jetzt sicher gehen, dass ich das korrekt verstanden hab: das soll schon in der DLL gesetzt werden, richtig? Nicht erst "während" des Konstruktors des eigentlichen TForm-Objekts? Da wäre es meiner Meinung nach nämlich zu spät, aber ich will da lieber nochmal nachfragen. Das sieht jetzt ungefähr so aus:

Delphi-Quellcode:

// In der DLL
procedure CreateSearch({... ;} AHnd: THandle); cdecl;
begin
  Application.Handle := AHnd; // hier ist das ja korrekt oder?
  FDynamicSearchDlg := TFormDynamicSearchDialog.Create({...});  // hier als Parameter wäre zu spät, richtig?
  // usw.
end;

// Im DLL-Interface (-> außerhalb der DLL, in der EXE drinnen sozusagen)
CreateSearch({...;}, Application.Handle);