TWinControl via TInterfacedObject via TInterfacedPersistent

[EWeiss]

Ich dachte eigentlich es hätte irgendwelche Vorteile.
Bisher kann ich keinen erkennen bei deiner Aussage.

Eher Nachteile falls jemand diese Klasse später mit WinControls nutzen möchte.
Vielleicht dann lieber gar nichts ändern.

Danke.

gruss

[EWeiss]

Zitat:

TInterfacedPersistent macht dabei keinen Sinn, denn es schaltet die Referenzzählung aus bzw. implementiert diese nicht.

Aber nur damit funktioniert es gerade weil die Referenzzählung ausgeschaltet ist.
Wenn ich tmpAudioVolume.Free aufrufe dann kracht es mit invalid Pointer weil noch 3 refcounter offen sind. (TInterfacedObject)
Habe es nur testweise mal versucht.

gruss

[Zacherl]

Ich denke, ich würde hier komplett anders vorgehen. Deine Komponente TAudioVolume muss die Interfaces IAudioSessionEvents, IMMNotificationClient, IAudioSessionNotification, IAudioEndpointVolumeCallback doch gar nicht öffentlich implementieren. Du könntest dafür eine weitere (private) Klasse in der gleichen Unit anlegen und Befehle von TAudioVolume an eine Instanz davon weiterleiten bzw. die Callbacks von der Instanz zur TAudioVolume Komponente. Also eine Art Proxy sozusagen. Von dem Proxy erstellt du dann pro TAudioVolume Instanz ebenfalls eine Instanz und gibst diese im Destructor frei (TAudioVolume besitzt also die Proxy Instanz). TAudioVolume selbst kannst du dann z.B. einfach von TObject ableiten.

[EWeiss]

Zitat:

Du könntest dafür eine weitere (private) Klasse in der gleichen Unit anlegen und Befehle von TAudioVolume an eine Instanz davon weiterleiten bzw. die Callbacks von der Instanz zur TAudioVolume Komponente.

Das war die vorherige Version..
Wir sind davon abgekommen weil es nicht möglich war die Interface in OnSessionCreate und Konsorte mit PostMessage weiterzuleiten.
Es ist auch keine Komponente sondern nur eine Klasse TAudioVolume.

TObject habe ich versucht dann kracht es gewaltig invalid pointer sagte ich schon.

gruss

[TiGü]

Zitat:

tmpAudioVolume.Free

Einfach nicht machen.
Extrahiere die wichtigsten Methoden von TAudioVolume in ein IAudioVolume und füge es deiner Klasse hinzu:

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

Delphi-Quellcode:

//Erzeugen in der Anwendung dann nur über:

var
  tmpAudioVolume: IAudioVolume;
begin
  tmpAudioVolume := TAudioVolume.Create; 
 ...
end;

[EWeiss]

Zitat von TiGü:

Zitat:

tmpAudioVolume.Free

Einfach nicht machen.
Extrahiere die wichtigsten Methoden von TAudioVolume in ein IAudioVolume und füge es deiner Klasse hinzu:

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

Delphi-Quellcode:

//Erzeugen in der Anwendung dann nur über:

var
  tmpAudioVolume: IAudioVolume;
begin
  tmpAudioVolume := TAudioVolume.Create; 
 ...
end;

Danke. Tigü

Ich denke werde es erst mal so belassen wie es ist.
Ich muss die Kontrolle darüber haben das Object selbst freigeben zu können.
Es war auch nur mal ein Test um zu sehen welche Auswirkungen das hat, haben könnte.

Ich denke auch das der Mixer jetzt fertig ist das mit den kleinen Problem was die Session angeht
liegt an der Audio Core selbst (Win7) die entläd diese manchmal nicht oder schickt kein Event.
Ist der Grund warum ich jetzt doch über die Prozesse gehen muss.

gruss

[Zacherl]

Zitat von EWeiss:

Wir sind davon abgekommen weil es nicht möglich war die Interface in OnSessionCreate und Konsorte mit PostMessage weiterzuleiten.

Denke mal du willst es jetzt eh nicht mehr ändern, aber mit "Weiterleiten" meinte ich im Grunde auch nur folgendes:

Delphi-Quellcode:

type
  TOnSessionCreate = procedure(...) of Object;

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

  TAudioVolumeProxy = class(TInterfacedObject, IAudioVolume, IAudioSessionEvents, IMMNotificationClient, IAudioSessionNotification, IAudioEndpointVolumeCallback)
  strict prviate
    FOwner: TAudioVolume;
  strict private
    procedure OnSessionCreate(...);
  ...

constructor TAudioVolume.Create;
begin
  inherited Create;
  FProxy := TAudioVolumeProxy.Create(Self);
end;

destructor TAudioVolume.Free;
begin
  FProxy.Free;
  inherited Destroy;
end;

procedure TAudioVolumeProxy.OnSessionCreate(...)
begin
  if Assigned(FOwner.FOnSessionCreate) then
  begin
    FOwner.FOnSessionCreate(...);
  end;
end;

TAudioVolume selbst hat hierbei praktisch gar keine eigene Funktionalität, sondern dient nur als Schnitstelle (Proxy sollte man vermutlich in Implementation oder sowas umbenennen).

[EWeiss]

Zitat:

Denke mal du willst es jetzt eh nicht mehr ändern, aber mit "Weiterleiten" meinte ich im Grunde auch nur folgendes:

Versuchen kann man es ja mal

gruss

[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.