Problem bei deltaX/Y Positionierung von Elementen

[wintermute]

Hi Christian,

ich hab hier grad einen Fall den ich leider nur relativ wage beschreiben kann
Ich hab ein Element in der Visu welches ich via deltaX und deltaY verschieben wollte, was auch bisher immer geklappt hatte. Jetzt hab ich den ganzen Kram in der Visu gruppiert und die "Berechnung" des Versatzes einem Baustein ueberlassen. Was auch in der Vorschau im Visu-Editor gut klappt - also so wie erwartet. Sobald ich aber die "echte" Visu nehme und dem KO (x|y) einen Wert zuweise, verschwindet mein Element komplett.

Jetzt hab ich das verlorenen Kind mal im Chromium-Dev-Mode gesucht und festgestellt, dass es schon noch da ist, nur eben sehr weit weg. Da steht zB "left: 682220" oder "top:449120". Hat etwas gedauert bis mir aufgefallen ist, dass da scheinbar nicht ein Offset addiert wird, sondern Strings verkettet werden... anders gesagt: die Koordinaten von dem Objekt sind 682,449. Will ich das nun um 100/100 verschieben wird da nicht etwa 782,549 draus, sondern 682100/449100. Was auch scheinbar von Edomi so an den Browser uebermittelt wird. Kann man (kurioserweise) umgehen, indem ich nicht "{split(0)}" bei deltaX, sondern statt dessen "+{split(0)}" eintrage.

Und weil ich ja auch gern lerne, hab ich die Hilfe gelesen, fand aber keinen Hinweis darauf.... kann es sein, dass da irgendwo ein "." anstatt eines "+" im Javescript steht?

[gaert]

Mh... Müsste ich mal nachstellen - wie genau sieht denn der KO-Wert beispielsweise aus? Wenn Du nur {split(0)} verwendest, sollte der KO-Wert z.B. "123|456" sein - dann würde/sollte "123" zurückgegeben werden.

Vorschau und reale Visu nutzen übrigens die selbe JS-Funktion, also kann's m.E. nur am Live-KO-Wert liegen...

[Simone]

Da oben steht doch die Berechnung des Versatzes macht der Baustein (den man nicht kennt?) split trennt doch nur die Werte und die kommen dann vom Baustein schon verkettet anstatt addiert? Wieso dann aber in der Vorschau und mit +{split(0)} korrekt?

[gaert]

Ich schätze mal, dass wintermute den "Separator" bei der Verkettung vergessen hat - also "123456" anstelle von "123|456". Somit liefert split(0) "123456" und split(1) ""

[Simone]

Glaube ich nicht sonst waer es 682100449100 oder 682449 (die 100 sind die pixel um die er es verschieben soll)

Eigentlich duerfte doch die visu den wert 100 nicht mehr kennen weil das doch der Baustein macht

aber das ist grosses

[gaert]

Achso... Jetzt raff' ich das Problem erst richtig

Stimmt: Aus {100+split(0)} wird in der Tat z.B. 100123 anstelle von 223... Das liegt wohl daran, dass JS "denkt" 100 bzw. 123 sei ein String...

Lässt sich (provisorisch) umgehen, indem man JS mitteilt, dass es sich um einen numerischen Wert handelt: {100+parseInt(split(0))}

Ich werde versuchen, dies noch irgendwie einzubauen - so pauschal geht das allerdings nicht, denn es könnte ja auch sein, dass man einen String von split() erwartet...

[gaert]

Ich hab' die Funktion mal angepasst - so sollte es universell klappen.

In der Datei "/usr/local/edomi/www/shared/js/main.js" die Funktion str_split() durch diese hier ersetzen: (und Browser refreshen)

    function str_split(x,pos,sep) { //Splittet den String x mittels sep (optional) und liefert den Wert mit dem Array-Index pos zurück
        if (!sep) {sep="|";}
        var n=x.split(sep);
        if (pos<n.length) {
            if (isNaN(parseFloat(n[pos]))) {
                return n[pos].toString();
            } else {
                return parseFloat(n[pos]);
            }
        } else {
            return null;
        }
    } 

Übrigens: Auch die anderen String-Funktionen liefern bislang immer STRING zurück - ich werde dies noch entsprechend anpassen...

EDIT:
Changelog sieht dann so aus:
x Visualisierung: Die String-Funktionen split(), left(), right() und mid() (bzw. str_...) geben nun ggf. einen Zahlenwert zurück, damit Berechnungen wie z.B. "{100+left(2)}" nicht zu einer String-Verkettung anstelle einer Addition führen

@wintermute: Danke für den Hinweis

[wintermute]

Danke, das funktioniert, macht aber nen anderen Teil kaputt o\
Ich habe einen Baustein der zB sowas hier rauswirft "22.2°/44%|#abcdef". Davon wurde bisher der erste Teil (also "22.2°/44%") als String in der Visu ausgegeben und der zweite Teil (also "#abcdef") hat die Vordergrundfarbe definiert. Letzteres geht zwar noch, aber ersteres wird jetzt (logischerweise) zu "22.2".
Ich habs zwar nicht probiert und bin auch nicht die grosse JS-Leuchte, aber ich schaetze mal von "3 kleine Schweinchen" wird jetzt auch nur noch die "3" ueberleben.

Ich taete mir dann eher helfen wollen, indem ich im Design anstatt "{split(0)}" ein "+{split(0)}" verwende, das fuehrt naemlich auch zum Ziel.

Was aber wohl auch geht (grad mal kurz probiert, aber nicht wirklich getestet) ist das hier:

// deleted

EDIT: und ja, Simone hat das Problem von Anfang an durchschaut

EDIT 2: Der urspruenliche Code hat ueberhaupt nicht funktioniert
Der hier aber wohl:

if (pos<n.length) {
  if (!isNaN(parseFloat(n[pos])) && isFinite(n[pos])) {
    return parseFloat(n[pos]);
  } else {
    return n[pos].toString();
  }
} else {
  return null;
}

[gaert]

Tja, das ist eben das Problem mit JS... Keine Typendeklaration.

Die m.E. robusteste Lösung wäre es, wenn man der Funktion den "Wunschtyp" mit auf den Weg geben würde - also STRING oder ZAHL... Alles andere ist seitens JS eine "Schätzung" - ist 22.2° nun ein String oder eine Zahl...

[wintermute]

Der JS-Code von oben macht aus 22.2° einen String und aus 22.2 eine Zahl.. sowohl der Versatz als auch das Darstellen von Strings mittels split() funktionieren damit - bei mir.
Und 22.2° ist ganz unzweideutig ein String, wenn man da ne Zahl draus machen will sollte man Number( davor schreiben, oder 0 addieren, oder so

[gaert]

Mit ° meinte ich das Grad-Symbol - kann ich hier nur nicht eingeben mit meiner spanischen Tastatur

Für mein Verständnis ist allerdings 22.2(Grad) ein String - eben wegen des Symbols... Warum übergibst Du überhaupt die Einheit mit dem KO-Wert?! Wäre es nicht "logischer", nur den Wert zu übergeben - z.B. "{...split()...}Grad"?

EDIT:
Übrigens ist isFinite() auch nicht das gelbe vom Ei... "1+2" ergibt true, während "1/2/3" false ergibt... Ja wat denn nu?! Man könnte beides sowohl als String als auch als "Formel" auffassen...

[gaert]

Im nächsten Update dann:

• Visualisierung: Die String-Funktionen split(), left(), right() und mid() (bzw. str_...) geben nun ggf. einen Zahlenwert zurück, damit Berechnungen wie z.B. "{100+left(2)}" nicht zu einer String-Verkettung anstelle einer Addition führen
  • Beispiele für den Ausdruck "{100+left(4)}":
  • KO=5: "105", KO=-5.1: "94,9", KO=5abcde: "1005abc", KO=abc567: "100abc5"

[wintermute]

Warum übergibst Du überhaupt die Einheit mit dem KO-Wert?! Wäre es nicht "logischer", nur den Wert zu übergeben - z.B. "{...split()...}Grad"?.

Der Behaglichkeitsbaustein baut aus den eingehenden Werten fuer Temperatur und Feuchte sowie der resultierenden Behaglichkeit einen String fuer die Visu. Der erste Teil ist der anzuzeigende Text, der zweite die Farbe, das KO wird gesplittet - der erste Teil wird (nunja) angezeigt, der zweite ist eine dynamische Farbe, das sieht dann zum Beispiel so aus: "12.3° / 45.6%|abcdef"
Ja, ich haette auch Temp/rH/Farbe nehmen koennen, hab ich aber irgendwie nicht getan. Und ich moechte das nu ungern aendern weil der eine oder andere das vllt schon benutzt und das dann unnoetige Aenderungen nach sich ziehen taete.
Das eigentliche Phaenomen ist mir bisher wohl deswegen nicht aufgefallen, weil ich bei Positionsverschiebungen immer ne Formel hatte und nicht einfach nur einen split-Wert.

[gaert]

Okay... Dann hoffe ich mal, dass durch meine Änderung nunmehr keine Probleme in anderen Zusammenhängen auftauchen - was eigentlich nicht passieren dürfte (bei anderen Nutzern meine ich, die left() usw. für andere Zwecke einsetzen).

Die Stringfunktionen verhalten sich dann demnächst also wie oben erläutert - ich hoffe damit kannst Du gut leben?

[wintermute]

Jo, passt fuer mich, danke