TWinControl via TInterfacedObject via TInterfacedPersistent

[EWeiss]

Meine Classe

Aktuell..

Delphi-Quellcode:

TOnSessionStateEvent = procedure(Sender: TCustomAudioVolume; NewState: integer) of object;

TCustomAudioVolume = class(TWinControl)
  //
end;

TAudioVolume = class(TCustomAudioVolume, IAudioSessionEvents, IMMNotificationClient,
  IAudioSessionNotification, IAudioEndpointVolumeCallback)
begin
// .. Inhalt jetzt egal
end

Ich verwende keine WinControls daher frage ich mich was besser wäre das Aktuelle oder diese hier.

TInterfacedObject..

Delphi-Quellcode:

TOnSessionStateEvent = procedure(Sender: TObject; NewState: integer) of object;

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

TInterfacedPersistent..

Delphi-Quellcode:

TOnSessionStateEvent = procedure(Sender: TPersistent; NewState: integer) of object;

TAudioVolume = class(TInterfacedPersistent, IAudioSessionEvents, IMMNotificationClient,
  IAudioSessionNotification, IAudioEndpointVolumeCallback)

welche vor bzw.. Nachteile würden sich dadurch ergeben?
wie sieht das dann mit create, inherited und Konsorte aus.

Ja bei TObject, TPersistent müsste ich Create ändern nur welche gesamt Auswirkung hätten diese Änderungen und sind sie sinnvoll.

Delphi-Quellcode:

public
  constructor Create; reintroduce;

Delphi-Quellcode:

constructor TAudioVolume.Create();
inherited Create();

gruss

[jaenicke]

Wenn du TWinControl nicht brauchst, macht es auch keinen Sinn davon abzuleiten.

Wenn du Interfaces benutzt, dann am besten richtig mit Referenzzählung, sprich mit TInterfacedObject. Und auch so, dass du nur über Interfaces mit den Objekten arbeitest und nie über Objektreferenzen. Denn nur so kannst du ausschließen, dass die Referenzzählung das Objekt freigibt, du aber noch eine Objektreferenz offen hast oder umgekehrt.

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

[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