TAudioVolume Komponente incl. System Mixer

[HolgerX]

Hmm..

Um eine Applikation direkt mit COINIT_MULTITHREADED zu starten, genügt eigendlich folgendes:

In der Projekt DPR :

uses
ActiveX,
ComObj,
...

und dann vor dem Application.Initialize; :

CoInitFlags := COINIT_MULTITHREADED;
Application.Initialize;

Damit sollte die (VCL) Applikation direkt als MULTITHREADED initialisiert werden.

(So geht es zumindestens unter D6 )

[EWeiss]

Zitat von HolgerX:

Hmm..

Um eine Applikation direkt mit COINIT_MULTITHREADED zu starten, genügt eigendlich folgendes:

In der Projekt DPR :

uses
ActiveX,
ComObj,
...

und dann vor dem Application.Initialize; :

CoInitFlags := COINIT_MULTITHREADED;
Application.Initialize;

Damit sollte die (VCL) Applikation direkt als MULTITHREADED initialisiert werden.

(So geht es zumindestens unter D6 )

Mag unter VCL so gehen aber nicht mit NonVcl.
Aber gut zu wissen wenn es geht

EDIT:
Wenn ich das mache in meiner DPR..

Delphi-Quellcode:

var
  HR: HRESULT;
begin
  HR := CoInitializeEx(nil, COINIT_MULTITHREADED);
  if HR <> S_OK then
    raise Exception.Create('Error : Unable to initialize Component Object Model');
  WinMain(hInstance, 0, nil, 0);

Dann schlägt CoInitializeEx fehl.
Ich muss quasi den von Delphi erstellten APARTMENTTHREADED erst mal beende.
Das ist aber ein Unart wenn Delphi das von sich aus macht.

Aber auch dann funktionieren die Events nicht.
function TAudioSessionNotification.OnSessionCreated(const NewSession: IAudioSessionControl): HResult;

Und dein Beispiel funktioniert nicht mit D2010.

Delphi-Quellcode:

program AudioVolumeAdj_Eng;

uses
  Forms,
  ActiveX,
  ComObj,
  VolumeTest_Eng in 'VolumeTest_Eng.pas' {Form1},
  AudioVolume in '..\AudioVolume.pas';

{$R *.res}

begin
  CoInitFlags := COINIT_MULTITHREADED;
  Application.Initialize;
//  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

gruss

[EWeiss]

Hier mal ein Test Projekt für die Events (Threads) so 100% funktioniert es nicht.

Da keine Rückantwort kam.. gelöscht.

gruss

[EWeiss]

Noch nicht ganz fertig aber zum Testen\Spielen sollte es reichen.
Wie gesagt immer noch die Event Probleme...
Nebenbei kein MemoryLeak auch nicht bei den Icons..

Wegen der CPU! Das muss ich alles noch optimieren.

gruss

[KodeZwerg]

Zitat von EWeiss:

Noch nicht ganz fertig aber zum Testen

Das andere Beispiel mit dem Event wo was krachen soll habe ich weder zum krachen noch sonst was bekommen, Edit1 blieb Edit1.

Zitat von EWeiss:

zum Spielen sollte es reichen.

Auf jeden Fall, funktioniert super bei mir (Windows 7 x64)

Zitat von EWeiss:

Wie gesagt immer noch die Event Probleme

Ist damit per timer/event zu prüfen ob ein Prozess dazugekommen/beendet wurde gemeint?

Zitat von EWeiss:

Wegen der CPU! Das muss ich alles noch optimieren.

Da mag ich nicht in Deiner Haut stecken, das sieht ja jetzt schon verdammt kompliziert aus.

Zitat von EWeiss:

Nebenbei kein MemoryLeak auch nicht bei den Icons

Dann bleib dem Treu, super Arbeit, mir gefällts

[EWeiss]

Zitat:

Da mag ich nicht in Deiner Haut stecken, das sieht ja jetzt schon verdammt kompliziert aus.

Den Timer auf 60ms hochsetzen wirkt schon wunder.
Das Problem ist halt das es keine Windows gibt die Controls bestehen nur aus reinen Bitmaps.
Deshalb muss ich um diese zu aktualisieren UpdateWindow verwenden und das verbraucht einiges an CPU.
Na ja mal schaun.

Zitat:

Das andere Beispiel mit dem Event wo was krachen soll habe ich weder zum krachen noch sonst was bekommen, Edit1 blieb Edit1.

Wenn man das starte und anschließend eine Audio Anwendung starte sollte es krachen..
Tut es bei mir zumindest.

Zitat:

Ist damit per timer/event zu prüfen ob ein Prozess dazugekommen/beendet wurde gemeint?

Richtig! Solange kann ich nicht darauf reagieren wenn die Events nicht funktionieren.

gruss

[KodeZwerg]

Zitat von EWeiss:

Richtig! Solange kann ich nicht darauf reagieren wenn die Events nicht funktionieren.

Könnte man das eventuell so Regeln?
Bei Programm Start wird ja Ermittelt was da so alles für Prozesse laufen die auch noch mit dem Mixer verbunden sind.
Da kann man doch bestimmt so etwas wie eine Liste anlegen für "hab diesen Prozess" oder noch besser, limitieren auf den Namen den dein Programm für die Prozesse anzeigt.
Nun ein Timer und die gleiche Prozedur durchlaufen lassen wie beim Start nur das dabei eine zweite Liste erstellt wird.
Die könnte man doch dann Gegenprüfen und bei Veränderung alles von vorne zeichnen wie bei Programm Start. Nur so ein Gedanke, ob der umzusetzen ist weiß ich nicht.

[HolgerX]

Hmm..

Wieso einen Thread machen, wenn die COM der App nur MULTITHREADED initiert werden muss??

Zitat von HolgerX:

Um eine Applikation direkt mit COINIT_MULTITHREADED zu starten, genügt eigendlich folgendes:

In der Projekt DPR :

uses
ActiveX,
ComObj,
...

und dann vor dem Application.Initialize; :

CoInitFlags := COINIT_MULTITHREADED;
Application.Initialize;

Damit sollte die (VCL) Applikation direkt als MULTITHREADED initialisiert werden.

Lt.

http://docwiki.embarcadero.com/Libra...bj.CoInitFlags

Gibt es diesen Parameter nicht nur in Delphi 6, sondern hoch bis 10 Tokyo!
Somit sollte dieser auch unter D2010 verfügbar sein.

Ich habe dass mit dem hier vorhandenen NotificationTest ausprobiert (ja, nach Anpassungen an und dann mit Delphi 6 !!) und habe alle Messages erhalten.

Habe ich das CoInitFlags auskommentiert, klappte es nicht mehr..

Wenn Du nun in deiner Unit (AudioSessionNotification) unten das

Delphi-Quellcode:

initialization
  CoInitFlags := COINIT_MULTITHREADED;

einbaust (Plus ActiveX, ComObj in die Uses), wird dies Verwendet, ohne die DPR ändern zu müssen. Es wird automatisch gesetzt, wenn deine Unit verwendet wird.

(Mit D6 ausprobiert !)