ComObject freigeben

[EWeiss]

Hi

Ein mit CreateComObject erstelltes objekt wie wird dieses unter Delphi
wieder freigegeben.

Delphi-Quellcode:

comObjType := CreateComObject(sCLSID) as IWMPEffects;

Reicht es wenn man

Delphi-Quellcode:

_IWMPEffects := nil;

setzt oder gibt es dafür einen speziellen Befehl.

EDIT:
Im moment verwende ich diese Funktion

Delphi-Quellcode:

function BASS_WMPVIS_Free(): boolean; stdcall;
begin

  if _IWMPEffects <> nil then
    begin
      try
        //_IWMPEffects._Release();
        _IWmpEffects := nil;
        Result := true;
      except
        Result := False;
      end;
    end else
      Result := true;

end;

Gebe ich das Obj über release frei dann crasht die Anwendung bei
_IWmpEffects := nil;

was wäre in dem Fall besser Release zu verwenden oder IWmpEffects auf nil zu setzen.
Ist in beiden fällen das object terminiert oder nicht ?

gruss Emil

[mkinzler]

Zitat:

_IWmpEffects := Unassigned;

[EWeiss]

Zitat:

Zitat von mkinzler

Zitat:

_IWmpEffects := Unassigned;

Da habe ich direkt wieder einen Fehler.
Für Unassigned muss ich ja die *.pas Variants einfügen da im projekt nicht vorhanden.

Das kommt dann dabei raus!
[Pascal Error] WMPUnit.pas(109): E2010 Incompatible types: 'IWMPEffects' and 'Variant'

gruss Emil

[mkinzler]

Das funktioniert nur bei OleVariant.

[mr2]

Delphi-Quellcode:

  _IWMPEffects := nil;

reicht vollkommen aus - der Delphi-Compiler generiert automatisch den _Release-Aufruf.
Unassigned sollte man nur verwenden, wenn man über späte Bindung (OleVariant) auf COM-Objekte zugreift.

mr2

[EWeiss]

Zitat:

Zitat von mr2

Delphi-Quellcode:

  _IWMPEffects := nil;

reicht vollkommen aus - der Delphi-Compiler generiert automatisch den _Release-Aufruf.
Unassigned sollte man nur verwenden, wenn man über späte Bindung (OleVariant) auf COM-Objekte zugreift.

mr2

ahh ... dann brauche ich den Release aufruf nicht.
dann wars doch nicht so verkehrt.

Direkt noch eine kurze frage für die zukunft!
Was ist generell besser

Delphi-Quellcode:

if Assigned(_IWMPEffects) then

oder der aufruf

Delphi-Quellcode:

if _IWMPEffects <> nil then

grundsätzlich denke ich das gleiche. Oder?

gruss Emil

[marabu]

Moin Emil,

verwende _Release() nur dann, wenn du vorher explizit auch _AddRef() verwendet hast.

Den Unterschied zwischen Assigned() und dem Vergleich mit nil kannst du im CPU-Fenster erkennen - es gibt keinen.

Freundliche Grüße

[EWeiss]

Zitat:

Zitat von marabu

Moin Emil,

verwende _Release() nur dann, wenn du vorher explizit auch _AddRef() verwendet hast.

Den Unterschied zwischen Assigned() und dem Vergleich mit nil kannst du im CPU-Fenster erkennen - es gibt keinen.

Freundliche Grüße

Danke , dachte nur es würde einen unterschied machen
da mitunter bei dieser abfrage
if _IWMPEffects <> nil then

eher eine fehlermeldung ausgelößt wird als bei Assigned.
Glaube ich zumindest bemerkt zu haben.

gruss Emil

[Ralf Kaiser]

Zitat:

Zitat von EWeiss

eher eine fehlermeldung ausgelößt wird als bei Assigned.
Glaube ich zumindest bemerkt zu haben.

gruss Emil

Nein, im Prinzip sind beide Abfragen gleich. Es gibt allerdings Situatuionen bei denen man nicht auf "= nil" testen kann: z.B. wenn man testen will ob ein Event bereits zugewiesen ist ("if Assigned(FOnClick) then...") da hier eine gehörige Portion "Compilermagie" im Spiel ist (Methodenzeiger bestehen ja eigentlich aus 2 Zeigern, einer aufs Objekt einer auf die Methode). Hier geht dann nur Assigned.

Ciao,
Ralf

[Bernhard Geyer]

1, Delphi-COM-Technisch reicht es aus alle Referenzen auf nil zu setzen. Im Hintergrund werden alle nötigen _Release-Aufrufe getätigt

2, Diverse COM-Server benötigen aufgrund ihrer internen Implementierung noch zusätzliche Quit, Exit oder Close-Aufrufe um intern aufzuräumen. Dies ist aber eher eine designschwäche der entsprechenden COM-Server

3, Manche Komponenten (z.B. Internet-Explorer) benötigen Teilweise _Release-Aufrufe das sie intern zu fehlerhaft implementiert sind bzw. intern sehr oft zirkuläre Referenzen haben womit sich COM-Objekte gegenseitig am leben erhalten