Eine Verbindung mit CreateOleObject wieder lösen

[Jörg Dähler]

Hallo
wer kann mir sagen wie ich eine Verbindung die ich per "CreateOleObject" hergestellt habe, wieder freigeben kann.
Nachdem ich diese Verbindung hergestellt und benutzt habe, möchte ich alle damit geladenen DLLs etc wieder freigeben.

Danke
JD

[Andreas Kosch]

Hallo,

der Client hat bei COM auf die Lebensdauer des aufgerufenen Servers nur einen indirekten Zugriff. Nur dann, wenn der letzte Client seinen letzten <b>Interface-Zeiger</b> auf diesen Server freigegeben hat und der Server nicht anderweitig (CoAddRefServerProcess oder Eintrag in der ROT) gesperrt ist, wird die Server-Instanz zerstört

[Jörg Dähler]

Ok, hier einige Details, die mein Problem verständlich machen sollen

Meine Anwendung benutzt Groupwise, um Daten einzulesen (dazu ist ein Anmelden notwendig). Wird nun z.B. in Groupwise eine Einstellung geändert, will Groupwise neu starten. Es beendet sich auch, wartet aber mit dem Starten bis meine Anwendung die Verbindung (momentan nur durch Beenden meines Progs) getrennt hat. Da dieses Verhalten aber nicht wünschenswert ist, möchte bzw. muss ich das manuell irgendwie lösen. Haben Sie eine Idee (Bsp. Quelltext bevorzugt) ?!

Mfg
Jörg Dähle

[Andreas Kosch]

Hallo,

wie sieht im Programm die Freigabe des Interface-Zeigers aus? Wie und wo (globale Variable, Objektfeld) wird dieser deklariert

[Andreas Kosch]

Hallo,

das folgende Beispiel demonstriert die Vorgehensweise bei der Automation von Microsoft Word:
<pre>
unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;

type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private-Deklarationen }
FWordSrv : OleVariant;
public
{ Public-Deklarationen }
end;

var
Form1: TForm1;

implementation

{$R *.dfm}

uses ActiveX, ComObj;

procedure TForm1.Button1Click(Sender: TObject);
begin
FWordSrv := CreateOleObject('Word.Application');
FWordSrv.Visible := True;
ShowMessage('Und Tschüss...');
FWordSrv.Quit;
FWordSrv := Null;
end;

end.
</pre>
Der Automation-Server Word.Application stellt extra die Interface-Methode Quit zur Verfügung, damit der Client die Verbindung sauber trennen kann (d.h. Word kann dann intern aufräumen). Da mir nicht bekannt ist, wie Groupwise intern funktioniert, würde ich zuerst einen Versuch mit der frühen Bindung machen. Was passiert, wenn der Interface-Variablen der Wert nil zugewiesen wird? Beendet sich dann GroupWise

[Jörg Dähler]

Hallo
danke für das Beispiel, allerdings ändert sich nichts an dem Verhalten. Eine Zuweisung von NIL ist nicht legal, auch unassigned ist nicht wirkungsvoll, das ist wirklich zum verzweifeln.

Hier ein Auszug
.
.
var
GWobj : Variant; // GW Variable

.
.

//Groupwise Objekt laden und dort anmelden
//Ist Groupwise noch nicht geöffnet geht der Anmelde-Dialog auf
procedure TFormSuchen.GWLogin(Sender: TObject);
begin
GWobj := CreateOleObject('NovellGroupWareSession');
try
RAobj := GWobj.Login('',''); // login to post office
except
MessageDlg('Unable to login!', mtError, [mbok], 0);
close;
end;
end;

procedure TFormSuchen.GWLogout(Sender: TObject);
begin
GWobj.Quit;
GWobj := NIL;
end;

Ich beobachte mit TaskInfo2000 mein Programm. Beim tracen werden nach dem Login dort jede Menge Groupwise DLL angezeigt, die auch dort nach dem Login verbleiben. Ich denke, genau das ist das Problem.

Danke & Gruß
Jörg Dähle

[Andreas Kosch]

Hallo,

was passiert, wenn GWobj <b>nicht</b> als Variant/OleVariant deklariert wird, sondern direkt vom entsprechenden Interface-Typ. Der Aufruf von CreateOleObject wird dann durch den entsprechenden CoXXX.Create-Aufruf ersetzt. Wass passiert dann, wenn diese Interface-Variable auf nil gesetzt wird?

Der Haken mit der späten Bindung via Variant-Interfacevariable liegt darin, dass der Client auf die Kooperation des aufgerufenen COM-Servers angewiesen ist. Microsoft Word stellt dazu die Methode Quit zur Verfügung. Mit der frühen Bindung über den nativen Interface-Zeiger wird die Kooperation erzwungen :-