Dynamische Designs & KO3

[wintermute]

Frage in kurz: kann es sein, dass das KO3 bei dynamischen Designs nicht bis zum dynamischen Design durchgereicht wird, sondern dort immer das KO1 ankommt?

Hintergrund: Ich versuche mich grad an einem Visu Element zur RGB Steuerung was im ersten Schritt aus einem Farbauswahl-Element (RGB) und einem Schieberegler (0-100%, Saettigung) bestehen soll - Farbauswahl klappt auch soweit, RGB-Wert wird in ein iKO geschrieben.
Fuer den Schieberegler habe ich jetzt eine dynamische Hintergrundfarbe definiert die einen Verlauf von 100% transparent hin zur ausgewaehlten Farbe darstellt - klappt soweit auch. Ein dynamisches Design ist definiert, der RGB-Wert wird an die Hintergrundfarbe uebergeben, die ist konkret wie folgt definiert:

-webkit-linear-gradient(left, #{#}00 0%, #{#}ff 100%)

Wenn ich den RGB-Wert nun via KO1 uebergebe passt alles, nur soll der Schieberegler halt Werte von 0-100 rauswerfen. Gebe ich den RGB-Wert an KO3 vor, so wird zwar das dynamische Design entsprechend ausgewaehlt, in der Hintergrundfarbe kommt aber immer KO1 an.
Ist das Verhalten Absicht? Falls ja, finde ich es unpraktisch und wenig sinnvoll

(Und ja, man kann das auch hinbekommen indem man ein Universalelement unter den Schieberegler legt und das einfaerbt, aber mir gehts hier mehr um den akademischen Charakter der Frage )

[gaert]

Ist wohl etwas unklar ausgedrückt in der Hilfe - das KO3 dient in der Tat nur der *Auswahl* des dyn. Designs. Für die {#}-Geschichte ist *immer* KO1 zuständig. Das wird auch so bleiben (um Deiner nächsten Frage zuvor zu kommen)

[wintermute]

Ok, danke

[vento66]

Hm bei mir hängts da aber. Ich habe am KO1 einen string mit

1|2|3|4|5| | | | |

am Universalelement wird mit

{split(0)}

der richtige Wert (1) angezeigt. Das dynamische Design wird aber nicht aktiviert, trotz Wertbereich von 1-100. An KO3 ist nichts verbunden...

[gaert]

Naja, "1|2|3..." ist ja auch nicht 1..100 split() hat mit der Design-*Auswahl* nichts zu tun - hier zählt der reine KO-Wert. Das war aber schon immer so...

[vento66]

Ok, wenn Du das sagst, ich hätte jetzt Stein und Bein geschworen, das das schon mal ging

[saegefisch]

Spannend, ich bin mir auch recht sicher, das mal gemacht zu haben... Aber egal, wenn es jetzt nicht geht, dann wäre es aber immerhin prima, wenn an KO 3 statt eines weiteren KOs (das per LBS erst entsprechend gefüllt werden müsste) alternativ auch "{split(0)}" ermöglicht werden würde (was sich dann implizit auf KO 1 bezöge). Generell beschrieben: Entweder GA/KO oder ein Formelkonstrukt in Bezug auf KO 1.
Damit wäre alles sehr flexibel in jede Richtung und auch gut lesbar/erschließt sich direkt und ohne unnötigen Aufwand zusätzlicher KO, wenn man die nicht ohnehin braucht. Kostet nix, ich weiß, aber macht halt unnötige LBS erforderlich. Ja, die kosten auch nix...

[gaert]

Nein, das ging noch nie. Denn: split() usw. sind JS-Funktionen und die Design-Auswahl ist eine PHP-Funktion - da bin ich mir seeehr sicher

Ich wollte diesen Mechanismus eher nicht mehr anfassen. Das ist alles kompliziert genug wie es ist - und ich denke, dass man schon einen sehr hohen Grad an Flexibilität zu Verfügung hat. Das sollte eigentlich für die meisten Bedürfnisse mehr als ausreichen - vergleicht dies mal mit dem HS (dem "großen" Bruder).

[saegefisch]

Frage ok, Antwort auch...

ABER: HS ist DEFINITIV kein großer Bruder - schon Version 1.06 spielte in einer andere Liga als der HS - ganz zu schweigen von 2.xx.

Ich würde eher sagen: Großvater - war mal gut, hat viel zu erzählen, war ein guter Grund, Dinge in Frage zu stellen und neu zu denken, aber für heutige Fragen nicht mehr passende Antworten (wobei: zugegeben kenne ich seinen aktuellen Stand heute nicht mehr)... ohne seine Leistungen der Vergangenheit im geringsten schmälern zu wollen; damals war er echt mal klasse...

[Winni]

Doch, die Selektion hat sich früher immer auf den ersten Wert bezogen, wenn das KO durch | getrennt war. Das war praktisch.

https://knx-user-forum.de/forum/proj...it-wert-des-ko