Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[crunchip]

@jb_sullivan das geht schon mit binding, hier mal ein anderes Beispiel
bzw, wenn wird dadurch die ganze Textzeile eingefärbt und nicht nur das eine Wort.
@SBorg ist der Binding Guru:blush: vllt weiss er, ob und wie das machbar ist

[JB_Sullivan]

@crunchip

und wo kommt so eine Binding Programmzeile in das Widget rein? Bei HTML?

[crunchip]

@jb_sullivan hab ich oben geschrieben, bei css Font & Text

[SBorg]

@jb_sullivan Viele Wege führen nach Rom :)
Da Bindings auch Ressourcen benötigen und du den String eh schon "selbst baust", würde ich es einfach dort ansiedeln und dann in der VIS per HTML-Widget ausgeben. Per Binding müsste man den String nach "AN / AUS" erst durchsuchen und dann selektiv färben (aber ebenfalls machbar).

Im Blockly:

Ladestation An: Text "e-Bike Ladestation ist<div style='color:green'>AN</div>"
Ladestation Aus: Text "e-Bike Ladestation ist<div style='color:red'>AUS</div>"

Für die Farbwerte gehen natürlich per # auch HEX-Werte...
Benötigt so keinerlei zusätzliche Ressourcen ;)

[JB_Sullivan]

@sborg

Da haben wir es wieder, ich bin einfach zu Alt und noch in der HTML Welt verankert. Genau den Ansatz hatte ich schon probiert aber halt als HTML <font color=red>AN</font>

Hat natürlich nicht funktioniert und darum habe ich nach einem anderen Ansatz gesucht.

Interessant ist, das der Blockly Weg über eine Variable (ColorEIN-Rot) auch nicht funktioniert hat. Aber auch mit deinen <div style> Ansatz funktioniert es leider nicht :(

So schaut es dann im VIS aus - er interpretiert den Code als Text (basic-string)

[SBorg]

@jb_sullivan Du hast ein "erstelle Text aus" bei den Prüfungen zu viel ;)

Blockly Export

<xml xmlns="https://developers.google.com/blockly/xml">
<block type="on" id=":PD,NTEl^9T/6i@Jb/]f" x="63" y="38">
<field name="OID">0_userdata.0.Dummy</field>
<field name="CONDITION">ne</field>
<field name="ACK_CONDITION"></field>
<statement name="STATEMENT">
<block type="update" id="{Bs2O!|X}z@tL6%OkM=2">
<mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation>
<field name="OID">0_userdata.0.Output</field>
<field name="WITH_DELAY">FALSE</field>
<value name="VALUE">
<block type="text_join" id="XA$^1CH$rQioQQ-ul=|">
<mutation items="2"></mutation>
<value name="ADD0">
<block type="text" id="jXg0YY6rYlBeop*r5gXm">
<field name="TEXT">blabla ist </field>
</block>
</value>
<value name="ADD1">
<block type="logic_ternary" id=".GtO.w^~G9V1MGJS^:VL">
<value name="IF">
<block type="on_source" id=")r3:dbhi02J=q(1d|IP)">
<field name="ATTR">state.val</field>
</block>
</value>
<value name="THEN">
<block type="text" id="xJ0z,}R34glB79WK$`">
<field name="TEXT"><div style='color:green'>AN</div></field>
</block>
</value>
<value name="ELSE">
<block type="text" id="?UMdV=Qoq-wjjvgV;F8">
<field name="TEXT"><div style='color:red'>AUS</div></field>
</block>
</value>
</block>
</value>
</block>
</value>
</block>
</statement>
</block>
</xml>

Anzeige dann per HTML-Widget und Binding auf den erzeugten DP.
Dummy = true/false
Output = Zeichenkette

Funzt: :grinning:
VIS.mp4

[JB_Sullivan]

@sborg

Ja, manchmal sieht man vor lauter klicken den Wald (Code) vor Bäumen nicht. Danke für den Hinweis bzgl. des doppelten "erstelle Text"

Trotzdem geht es mit einem Basic String im VIS nicht. Man muss einen Basic String unescaped nehmen.

Jetzt habe ich aber das Problem, das er mir für das zweite Wort einen Zeilenumbruch rein bastelt. Hat auch nichts mit der Widget Größe zu tun. Kann ich groß machen wie ich will, er bricht mir das farbige Wort immer in darunter liegende Zeile um.

[SBorg]

@jb_sullivan :grin:
Ersetze einfach "div" durch "span" --> dann bleibt es in einer Zeile ;)

[JB_Sullivan]

@sborg

Verdammte Hacke - habe ich mich schon wieder irgend wo vertippt und sehe es nicht?

Bei zwei Einträgen ist der Zeilenumbruch weg, bei zweien ist er geblieben (Cache gelöscht und F5 gedrückt habe ich schon) :persevere: Aber interessanter Weise bei nur einem der beiden Eintrage (AN)

EDIT: Hmmm - ist wohl doch ein Chrome Cache Problem. Mit anderen Browsern und Endgeräten ist alles OK

[SBorg]

@jb_sullivan Noch Vierbesserungspotential: schau dir mal mein "prüfe" an.
Du moppelst doppelt ;)
wenn Licht an, dann prüfe Licht an = wahr dann..., sonst prüfe _Licht an = falsch dann...
Du hast aber doch schon Eingangs geprüft "wenn Licht an...", dann brauchst du wenn es "an" ist nicht nochmal prüfen ob es "an" ist.

Wenn bspw. dein "Verbraucher_x" true ist, ist er schon "wahr". Da braucht es nicht nochmals eine Prüfung ob er "wahr" ist. Du prüfst hier quasi sind Äpfel Äpfel? Das Ergebnis wird immer "wahr" sein. Mit deinem Term hast du eine Abfrage ist 1=1? Das Ergebnis der Abfrage dürfte ziemlich eindeutig sein :grin:

[JB_Sullivan]

@sborg

Gefahr erkannt - Gefahr gebannt ;)

Ich sagte ja, man probiert soviel hin und her, klickt hier und da, verwirft es wieder und macht was neues, geht zwischendurch was essen usw. dann bleiben da solche "Versuchsleichen" einfach mal unbeabsichtigt drin.

So, Prüfung, ob ein Apfel auch ein Apfel ist, ist raus ;)