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:

Zitat von EWeiss (Beitrag 1404100)

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:

Zitat von EWeiss (Beitrag 1404185)

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

Seh ich auch so.

[Zacherl]

Zitat:

Zitat von Schokohase (Beitrag 1404183)

@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

Delphi-Quellcode:

TAudioVolume

als Objektreferenz gehalten werden, nicht als Interface. Erzeugen im Constructor und Freigeben im Destructor.

Delphi-Quellcode:

TAudioVolume

selbst implementiert dann gar kein Interface mehr und braucht auch nicht von

Delphi-Quellcode:

TInterfacedObject/TInterfacedPersistent

abzuleiten, sondern nur vom guten alten

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von Zacherl (Beitrag 1404219)

Zitat:

Zitat von Schokohase (Beitrag 1404183)

@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

Delphi-Quellcode:

TAudioVolume

als Objektreferenz gehalten werden, nicht als Interface. Erzeugen im Constructor und Freigeben im Destructor.

Delphi-Quellcode:

TAudioVolume

selbst implementiert dann gar kein Interface mehr und braucht auch nicht von

Delphi-Quellcode:

TInterfacedObject/TInterfacedPersistent

abzuleiten, sondern nur vom guten alten

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von TiGü (Beitrag 1404228)

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)

Delphi-Quellcode:

AddRef

Aufrufe generiert ... aber das sollte dann ja eigentlich nicht am Interface bzw.

Delphi-Quellcode:

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

Delphi-Quellcode:

IAudioSessionControl

per

Delphi-Quellcode:

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

Delphi-Quellcode:

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

Delphi-Quellcode:

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 }