TWinControl via TInterfacedObject via TInterfacedPersistent

[Schokohase]

@Zacherl

Mit der Anleitung kann man allerdings nur Schiffbruch erleiden, oder? Wo ist denn jetzt der Unterschied zu der vorherigen Situation?

- TAudioVolume erzeugen
- Über TAudioVolumeProxy eine Interface-Instanz weiterreichen
- TAudioVolume freigeben
- Es knallt, wenn die Interface-Instanz auf nil gesetzt wird.

Dieses Verhalten hatte der TE schon selber gebaut und auch noch mit viel weniger Code.

Zitat von EWeiss:

Wenn ich tmpAudioVolume.Free aufrufe dann kracht es mit invalid Pointer weil noch 3 refcounter offen sind. (TInterfacedObject)
Habe es nur testweise mal versucht.

[EWeiss]

Um was es mir ging..
Ist die Unterschiede zu erfahren was ist besser, schneller bzw. Korrekter in der Ausführung.
Wenn ich keine WinControls verwende macht es eigentlich keinen sinn darauf abzuleiten genauso wenig wie auf TComponent.

Es stört mich nicht weiter da es funktioniert aber einen sinn ergibt das nicht wirklich.

Ich könnte hier einfach tmpAudioVolume.Free mit tmpAudioVolume := Nil ersetzen.
Aber es hängt noch mehr davon ab denn in Destroy müssen viele Dinge freigegeben werden.
Deshalb wäre das keine Lösung.

gruss

[freimatz]

Zitat von EWeiss:

Wenn ich keine WinControls verwende macht es eigentlich keinen sinn darauf abzuleiten genauso wenig wie auf TComponent.

Seh ich auch so.

[Zacherl]

Zitat von Schokohase:

@Zacherl

Mit der Anleitung kann man allerdings nur Schiffbruch erleiden, oder? Wo ist denn jetzt der Unterschied zu der vorherigen Situation?

- TAudioVolume erzeugen
- Über TAudioVolumeProxy eine Interface-Instanz weiterreichen
- TAudioVolume freigeben
- Es knallt, wenn die Interface-Instanz auf nil gesetzt wird.

Verstehe ich nicht. Der Proxy soll innerhalb von TAudioVolume als Objektreferenz gehalten werden, nicht als Interface. Erzeugen im Constructor und Freigeben im Destructor. TAudioVolume selbst implementiert dann gar kein Interface mehr und braucht auch nicht von TInterfacedObject/TInterfacedPersistent abzuleiten, sondern nur vom guten alten TObject .

Was intern mit dem Proxy passiert ist dadurch streng reguliert (da die Proxy Instanz privat ist, nie als Interface angesprochen wird und Erzeugung und Freigabe von TAudioVolume geregelt wird.

[EWeiss]

funktioniert leider nicht und ich musste einiges umbauen.

FProxy.Free; invalid Pointer
Ich lasse es jetzt wie es ist.

gruss

[TiGü]

Zitat von Zacherl:

Zitat von Schokohase:

@Zacherl

Mit der Anleitung kann man allerdings nur Schiffbruch erleiden, oder? Wo ist denn jetzt der Unterschied zu der vorherigen Situation?

- TAudioVolume erzeugen
- Über TAudioVolumeProxy eine Interface-Instanz weiterreichen
- TAudioVolume freigeben
- Es knallt, wenn die Interface-Instanz auf nil gesetzt wird.

Verstehe ich nicht. Der Proxy soll innerhalb von TAudioVolume als Objektreferenz gehalten werden, nicht als Interface. Erzeugen im Constructor und Freigeben im Destructor. TAudioVolume selbst implementiert dann gar kein Interface mehr und braucht auch nicht von TInterfacedObject/TInterfacedPersistent abzuleiten, sondern nur vom guten alten TObject .

Was intern mit dem Proxy passiert ist dadurch streng reguliert (da die Proxy Instanz privat ist, nie als Interface angesprochen wird und Erzeugung und Freigabe von TAudioVolume geregelt wird.

Aber auch nur, wenn Emil den Proxy von TInterfacedPersistent (oder System.Generics.Defaults.TSingletonImplementation) ableitet, ansonsten hat er wie im Post darüber zu lesen für ihn unverständliche Invalid Pointer Zugriffe und er resigniert.

[Zacherl]

Zitat von TiGü:

Aber auch nur, wenn Emil den Proxy von TInterfacedPersistent (oder System.Generics.Defaults.TSingletonImplementation) ableitet, ansonsten hat er wie im Post darüber zu lesen für ihn unverständliche Invalid Pointer Zugriffe und er resigniert.

Stehe irgendwie auf dem Schlauch grade. Wenn er den Proxy als Klasseninstanz erzeugt und die Variable, in der er die Instanz speichert, auch vom Typ der Klasse (nicht des Interfaces) ist, dann sollte der RefCount doch eigentlich garantiert 0 sein. Außer natürlich, es werden an späterer Stelle doch noch (wie auch immer) AddRef Aufrufe generiert ... aber das sollte dann ja eigentlich nicht am Interface bzw. TInterfacedObject selbst liegen, sondern ein Programmierfehler sein, oder liege ich hier falsch?

[Schokohase]

Hast du dir schon mal überlegt, warum dieser Proxy-Typ

Delphi-Quellcode:

TAudioVolumeProxy = class( TInterfacedObject, 
  IAudioVolume, 
  IAudioSessionEvents, 
  IMMNotificationClient, 
  IAudioSessionNotification, 
  IAudioEndpointVolumeCallback)

diese Interfacs in der Deklaration aufweist?

Evtl. weil die verwendet werden um sich z.B. an einem IAudioSessionControl per HRESULT RegisterAudioSessionNotification( [in] IAudioSessionEvents *NewNotifications ); anzumelden, weil diese Interfaces ansonsten nutzlos wären wenn man die gar nicht verwendet?

[Zacherl]

Sehe ich kein Problem, sofern man ordnungsgemäß auch wieder UnregisterAudioSessionNotification verwendet. Ich meine "irgendwo" müssen die Referenzen doch geleaked werden. Die entstehen ja nicht von alleine. Dann einfach die Referenzzählung zu deaktivieren, indem man TInterfacedPersistence verwendet, kann doch eigentlich nicht Sinn der Sache sein.

[Schokohase]

Wenn du dir selber aber die Interface Referenz nicht merkst
(dein Beispiel-Code)

Delphi-Quellcode:

TAudioVolume = class(TObject)
  strict private
    FProxy: TAudioVolumeProxy;
  strict protected
    FOnSessionCreate: TOnSessionCreate;
  public
    property OnSessionCreate: TOnSessionCreate read FOnSessionCreate write FOnSessionCreate;
  ...

und du gibst eine Interface-Referenz davon heraus, dann tickt ab da die RefCount-Bombe und die kann zu jedem Zeitpunkt platzen.

Delphi-Quellcode:

begin
  RegisterAudioSessionNotification(FProxy);
  UnregisterAudioSessionNotification(FProxy);
end; { bumm, wenn diese Methode verlassen wird, denn wird FProxy zerstört }