Etwas ist mir beim rummspielen schon aufgefallen und zwar wenn die Balken ihre Farbe ändern oder auch kurz davor verschwinden die "Zahlen"
Zeilen 171, 172 und 172 auskommentieren/löschen, Zeilen 164, 165 und 166 aktivieren.
Das Verschwinden beruht auf der einfachen Tatsache, dass ein Control in den Vordergrund geholt wird, sobald es angesprochen wird und somit alle darunterliegenden Controls an den überlappenden Stellen überdeckt.
Ich kenne ein paar Methoden, die dem entgegenwirken:
- Die Hintergrundfarbe eines Controls auf "unsichtbar" setzen, damit darunterliegende Controls durchscheinen können
- Die Transparenz eines Controls ändern, damit darunterliegende Controls durchscheinen können
- Über den Controls ein Child-Window mit transparentem Hintergrund erstellen, in diesem dann die Control mit transparenter Hintergrundfarbe erstellen, die nicht überdeckt werden sollen.
Hier wird auf einen Blick erkennbar, dass der Kernpunkt bei allen Methoden die Transparenz ist, welche naturbedingt aber (leider) auch den (unerwünschten) Nebeneffekt mit sich bringt, dass sie sich auf die Farben der sich überlappenden Controls auswirkt. Hier muss man also mit den Transparenzen/Farben experimentieren, um ein ansprechendes Ergebnis zu erhalten.
Ein völlig anderer Weg wäre, die komplette Progressbar mit GDIplus zu erstellen, wofür es bereits eine UDF von @progandy gibt. Leider stürzen beide Examples bei mir (Windows 10 X64) schon nach kuzer Zeit ab.
Ich experimentiere noch...
Und dann hätte ich noch gern die Farbe der Anzeige geändert
Anzeige --> Progressbar
Farben und Transparenzen kannst du in der Demo mit den globalen Variablen $g_aColors, $g_iProgressWinTransparency und $g_iProgressBarTransparency bestimmen. Beim Erzeugen des Child-Windows für die Progressbars besorge ich mir nun die Hintergrundfarbe des Parent-Windows. Die brauchst du also nur dann ändern, wenn es nicht dieselbe Hintergrundfarbe haben soll.
Im Laufe des Abends, spätestens aber morgen, schiebe ich eine aktualisierte Version der Demo hoch... muss da aber erst noch ein paar Sachen korrigieren.
Jetzt noch mal zu den Werten. Müssen diese fest programmiert werden von Dir zwegs Umrechnung?
Nein... in der Demo verwende ich der Einfachheit halber fixe Werte, in der fertigen Version ist die Umrechnung selbstverständlich anpassbar - die Sensorwerte werden dann entweder an eine Funktion übergeben, welche die korrigierten Werte als Ergebnis liefert, oder die Umrechnungsfaktoren werden als globale Variablen/Konstanten deklariert.
Und das es so eine Herausforderung ist war mich echt nicht bewusst
Wenn du für die Progressbars keine Skala brauchst, würde sich die Herausforderung damit auf 30% reduzieren...