Interface und Object

[hanspeter]

Noch eine Verständnisfrage zu Interfaces. Vielleicht hat wer einen Tip.

Ich übergebe ein IBConnect an eine Dll über ein Interface.
(Ich verwende IBDAC)

Das Interface ist declariert als SetConnection(IbConnect).

Auf der dll Seite verwende ich die übergebene Connection zur internen Initialisierung
einer temporären Connection.

InterneConnection.AssignConnect(externeConnection)

mit
InterneConnection.AssignConnect(nil);
gebe ich diese wieder frei.

Mein Problem: in einigen dll geht das problemlos.
In anderen dll bringt das nachfolgende Öffnen einer mit der Transaction verbundenen Query eine Speicherschutzverletzung
in der Query.

Der Quelltext für die Initialisierung ist in allen Modulen gleich.
Wo liegt hier ein Fehler?

Gruß
Peter

[Elvis]

Sorry, aber du musst schon die Deklaration des Interfaces sowie die Signaturen aller Methoden zeigen, denen du das Interface übergibst.
Erst dann kann man erahnen was schief geht.

Kleiner Schuss ins Blaue. Vllt klärtsich deinProblem damit, aber es gibt die auf jeden Fall einen Hinweis welche Infos wir brauchen.
Bei Methoden ist generell die Signatur WICHTIG, genauso wo/ob du die Interface-Referenz ablegst.

• Du verwendest das Interface auch als Objekt innerhalb der Echse? :?
  • Alle parameter, denen du das Interface übergibst sind const? gut :-)
  • Du weist es keiner globalen Variable und/oder einem Feld einer Klasse/Record zu? gut :-)
• Du verwendest das Interface nur als Interface in Echse und DLL
  • Du hast keinerlei Kreuzverweise, die das Interface länger am leben halten oder vorzeitig zerstören können? (TAggregatedObject) gut :-)
• Du verwendest etwas von dem Interface als Objekt in der DLL? ganz böse :-(
  -> Dann WIRD es irgendwann knallen, und das würde auch erklären, warum es nur manchmal knallt.

[hanspeter]

Zitat:

Zitat von Elvis

Sorry, aber du musst schon die Deklaration des Interfaces sowie die Signaturen aller Methoden zeigen, denen du das Interface übergibst.
Erst dann kann man erahnen was schief geht.

Kleiner Schuss ins Blaue. Vllt klärtsich deinProblem damit, aber es gibt die auf jeden Fall einen Hinweis welche Infos wir brauchen.
Bei Methoden ist generell die Signatur WICHTIG, genauso wo/ob du die Interface-Referenz ablegst.

Erst mal danke für die Tips.
Ich verwende das Hydra-Plugin von Remobjects.
Das Interface ist für alle Module gleich und so definiert :

Delphi-Quellcode:

type
  { Database }
  IAutPluginInterface = interface(IHYVisualPlugin)
  ['{E22DF92D-9B38-4DA0-BD05-0AD08E7238D2}']
    procedure InitDatabase(System, Data : TIBCConnection; IniFileName : string; Style : integer);
    procedure InitData(Kommando : Char; RID,PID: string; PRID: Integer);
    procedure GetMetrics(out Width,Height : integer);
    Function  GetStatus(Kommando : Char): integer;
    Function  GetInfo(Kommando : Char) : string;
  end;

Das Problem war wohl, das ich in der dll nicht visible Komponenten in einem TDataModule als Container gehalten habe.
Das scheint, insbesondere beim Release, Probleme zu bereiten.
Verwende ich als Container eine Form, dann habe ich wesentlich weniger Probleme.
Das Programm habe ich jetzt so geändert, das ich statt Server Connection Servername und Datenbankname übernehme und
in der dll eine neue Connection anlege. (Bei Firebird ist das ja im Hinblick auf die Anzahl der Lizenzen egal.)
So richtig glücklich macht mich dieses Plugin-System aber nicht.
Ich muss alle Module, welche ein Registerclass enthalten, als Laufzeit - bpl bereitstellen.

Versuchsweise habe ich jetzt das gesamte Reportsystem des Programms in einen Com-Server ausgelagert.
Ich bin noch am Testen habe aber noch keine Probleme finden können und diese Lösung macht eigentlich einen guten Eindruck.

Gruß
Peter