TAudioVolume Komponente incl. System Mixer

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1402107)

Zitat:

Zitat von EWeiss (Beitrag 1402105)

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.

Das wäre zwar ohne Aufwand möglich aber nicht sinnvoll.
Das Event muss von Windows selber kommen.
Ansonsten muss ich in einem Thread immer diese Liste überprüfen das wäre .. hmmm sagen wir mal schlecht.

Schade nur das niemand sagen kann woran es liegt und bereit ist zu helfen.

Nebenbei wenn ich wollte kann ich alle Controls zur Laufzeit auf andere Positionen verschieben. :)
Dazu muss ich nur eine einzelne Zeile deaktivieren.

gruss

[TiGü]

Beispiel für die Anwendung der Events, Notifications und Callbacks in der Hauptkomponente TAudioVolume. Beachte die neuen Methoden am Ende der Unit AudioVolume.pas.

Sollte in Delphi 2010 das hier nicht verfügbar sein:

Delphi-Quellcode:

TThread.Current.ThreadID

dann kannst du das mit

Delphi-Quellcode:

GetCurrentThreadId

ersetzen.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1402159)

Beispiel für die Anwendung der Events, Notifications und Callbacks in der Hauptkomponente TAudioVolume. Beachte die neuen Methoden am Ende der Unit AudioVolume.pas.

Sollte in Delphi 2010 das hier nicht verfügbar sein:

Delphi-Quellcode:

TThread.Current.ThreadID

dann kannst du das mit

Delphi-Quellcode:

GetCurrentThreadId

ersetzen.

Danke!
Werde es mir mal reinziehen.

gruss

[EWeiss]

@Tigü
Sieht gut aus ;) Vielen Dank dafür.

Werde mich damit weiter auseinandersetzen und schauen ob ich damit das Event ans laufen bekomme.
Im Moment nach dem Sortieren der Units und dem neu ausgerichteten Projekt lösen diese leider immer noch nicht aus. (Win7)

gruss

[SearchBot]

Hallo, bin hier vorgestern quer reingestolpert, weil ich gerade eine SessionVolume-Steuerung gesucht habe (also nicht MasterVolume).

Die Komponente ist toll :thumb:

Aber es ist für meine Verwendung schon zu viel drauf. Mir reicht der Schieberegler :stupid:

Leider gibt es da keine visible-Eigenschaften für die verschiedenen Elemente und die Höhe der Komponente läßt sich auch nicht verringern (zB wenn man das Icon oben weglässt). :idea:

Wäre es viel Arbeit, wenn die einzelnen Elemente eine visible-Eigenschaft :idea: bekämen?

[EWeiss]

Zitat:

Wäre es viel Arbeit, wenn die einzelnen Elemente eine visible-Eigenschaft bekämen?

Entschuldige bitte... Ich möchte nicht unhöflich sein.

Aber der Quelltext wurde veröffentlicht also steht es dir frei zu ändern was du willst.
Es wäre jedoch schön wenn du\ihr den Header der Komponente bestehen lasst.

TIP:
Lade dir von meiner Skined Anwendung die TAudioVolume LIB herunter.. diese ist ganz ohne Komponente so kannst du
selbst bestimmen ob und welche Art von Trackbar, Icons usw. du verwenden willst.

Zitat:

Werde mich damit weiter auseinandersetzen und schauen ob ich damit das Event ans laufen bekomme.

Es scheint so zu sein das W10 und W7 die Komponente bzw. die Events unterschiedlich behandeln.
Unter W10 scheint das Event zu funktionieren aber in W7 nicht.
Deshalb werde ich wohl ohne separaten Thread für die Events nichts machen können.

gruss

[EWeiss]

Neue Version..

Zitat:

v1.0.4 (15 Mai 2018)
- PostMessage für die Events entfernt
Events, Notifications und Callbacks wurden direkt in die Class TAudioVolume integriert
somit ist ein PostMessage für die Events nicht mehr von nöten
(by TiGü)

Danke für deine Mitarbeit.

gruss

[TiGü]

Gern!

Kann es sein, dass das Aufrufen der Callback von IAudioSessionNotification abhängig ist vom Treiber?
Der Treiber kann, muss das aber nicht implementieren.
Zumindest sieht das auf den ersten Blick so aus, wenn man sich die Wine-Quelltexte anschaut.

[TiGü]

Siehe Zeile 605:
https://github.com/wine-mirror/wine/...vapi/devenum.c

verweist auf Zeile 55:
https://github.com/wine-mirror/wine/...api/mmdevapi.h

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1402248)

Siehe Zeile 605:
https://github.com/wine-mirror/wine/...vapi/devenum.c

verweist auf Zeile 55:
https://github.com/wine-mirror/wine/...api/mmdevapi.h

Sorry ich verstehe nicht auf was du hinaus willst.

Wenn ich CoInitializeEx in einem Thread aufrufe dann bekomme ich das Event, ob es jetzt mit deiner Änderung funktioniert muss ich erste noch testen.
Was ich aber weis dass das Event unter Win10 unterschiedlich ist dort soll es funktionieren während es in Win7 nicht gehen soll.

Aber nur vom Hörensagen bestätigt hat mir das noch niemand.
Zumindest hast du mir letztens gesagt das die Events bei dir funktionieren ob es nun am Konsolen Programm lag oder an der Windows Version kann ich nicht mit Bestimmtheit sagen.

Zur zeit verwende ich CoInitializeEx nicht weil Delphi es automatisch aufruft "COINIT_APARTMENTTHREADED"
Delphi pfuscht mir irgendwie dazwischen was das soll keine Ahnung! Ist mir unverständlich.
Kein Sprache Framework soll bestimmen ob ich und wie ich CoInitialize aufrufe das sollte die Anwendung entscheiden nicht das Sprache Framework.

gruss