Slider: Position falsch?

[tuxedo]

slide.js ?? Wo sollte die denn liegen? Hab keine gefunden.

[update]

hab sie. ich teste ...

[tuxedo]

So, hier der Output meiner Page:

Value: 100, Max/Min: 100, %: 100 => 100
Value: 100, Max/Min: 100, %: 1000 => 1000
Value: 3, Max/Min: 7, %: 29 => 29
Value: 3, Max/Min: 7, %: NaN => NaN
Value: 100, Max/Min: 100, %: 100 => 100
Value: 100, Max/Min: 100, %: 1000 => 1000

Sind drei Slider auf der Seite.

Einer der 1..8 anzeigen soll und korrekterweise auf 3 steht.
Zwei die 0..100 anzeigen sollen und auf 100 eingestellt sind, aber der Slider falsch steht.

Der Code dazu:

  function transformSlider( value, handle )
  {
    if (!$main.data('disableSliderTransform')) {
      if (!isNaN(value)) {
        var sliderMax = $(handle).parent().slider("option","max")+($(handle).parent().slider("option","min")*-1);
        var percent = Math.round((100/sliderMax)*(value+($(handle).parent().slider("option","min")*-1)));
        console.log("Value: "+value+", Max/Min: "+sliderMax+", %: "+percent+" => "+percent);
        $(handle).css('transform', 'translateX(-'+percent+'%)');
      }
    }
  }

[jolt]

Kannst du bitte noch zusätzlich:

$(handle).parent().slider("option","max")

und

$(handle).parent().slider("option","min")

ausgeben. value scheint ja ok zu sein, also am Backend liegt es eher nicht.

[tuxedo]

Mach ich sofort. Wenn ich min=1 und max=100 in der config einstelle, dann geht's. Muss am min oder so liegen. Bin selbst grad am durchprobieren/rechnen.

[tuxedo]

So, die gewünschten Werte mit ausgegeben.

Hab nun 3 Slider:

* 1..8 mit Wert=3
* 1..100 mit Wert=100
* 0..100 mit Wert=100

Die ersten beiden sind korrekt. Letzterer hat die Fehlberechnung.

min=1
max=100
Value: 100, Max/Min: 99, %: 100 => 100
min=1
max=100
Value: 100, Max/Min: 99, %: NaN => NaN
min=1
max=8
Value: 3, Max/Min: 7, %: 29 => 29
min=1
max=8
Value: 3, Max/Min: 7, %: NaN => NaN
min=0
max=100
Value: 100, Max/Min: 100, %: 100 => 100
min=0
max=100
Value: 100, Max/Min: 100, %: 1000 => 1000

Code:

  function transformSlider( value, handle )
  {
    if (!$main.data('disableSliderTransform')) {
      if (!isNaN(value)) {
        var sliderMax = $(handle).parent().slider("option","max")+($(handle).parent().slider("option","min")*-1);
        var percent = Math.round((100/sliderMax)*(value+($(handle).parent().slider("option","min")*-1)));
        console.log("min="+$(handle).parent().slider("option","min"));
        console.log("max="+$(handle).parent().slider("option","max"));
        console.log("Value: "+value+", Max/Min: "+sliderMax+", %: "+percent+" => "+percent);
        $(handle).css('transform', 'translateX(-'+percent+'%)');
      }
    }
  }

[tuxedo]

Ich kommt nicht drauf warum mit value=100, min=0 und max=100 einmal 100 und einmal 1000 raus kommt...

[tuxedo]

Beim zweiten mal ist value nicht 100, sondern "100". Also ein String statt ein Integer. Und da scheint in der Prozentrechnung eine 0 konkateniert, statt addiert zu werden. Folglich wird aus "100" dann "1000" und nicht 100+(-0) = 100

Ich schau mal woher das ganze beim zweiten mal kommt.

[update]

Der zweite Aufruf kommt aus templateengine.js, aus der Update-Funktion um Zeile 319.

In slide.js wird geprüft ob es eine Zahl ist. Aber JS wertet das 100 sowie "100" gleichermaßen als Zahl.
Zwinge ich in slide.js die "Zahl" in eine Zahl:

 if (!isNaN(value)) {
        value = parseFloat(value);

dann klappt's.

Hätte man auch nach int parsen können. Aber ich weiß noch nicht ob ein Slider auch mit Dezimalzahlen umgehen können muss/darf.

Hab ich das jetzt als Bug entlarvt? Oder ist irgendwo ein Denkfehler drin?

[update]
Hab dann auch ein Erweiterung des Sliders um "readonly" realisiert. Hatte ich hier danach gefragt: https://knx-user-forum.de/forum/supp...ad-only-slider

Jetzt passt alles. Super Sache. Warte noch auf das Feedback und mache dann einen pull-request.

[Chris M.]

JavaScript ist verdammt tricky wenn es um Zahlen in Strings geht. Ich würde mir da immer wieder eine streng typisierte Sprache wünschen (zumindest optional...).

Zum konkreten: Slider dürfen auch Dezimalzahlen enthalten (z.B. wenn man per Slider eine Temperatur einstellen möchte)

=> Mach gerne mal einen Pull-Request
(Wenn auch das readonly drinnen ist kommt's zum Gewissenskonflikt, da wir eigentlich Feature Freeze haben. Mal schaun was das Code Review dazu sagt, evtl. kann ich ein Auge zudrücken )

[jolt]

Für readonly bitte einen extra Pull Request aufmachen, danke

[tuxedo]

Ich glaub ich brauch etwas git Nachhilfe:

Ich habe in meinem Fork eine Änderung commited und auf GH gepushed. Dann hab ich daraus einen Pull-Request gemacht (#203).

Jetzt habe ich eine weitere lokale Änderung commited (slider parsefloat-fix) und ebenfalls auf GH gepushed. Wie mache ich jetzt einen weiteren Pull-Request der nicht auch noch die File aus dem ersten Pull-Request beinhaltet?

[jolt]

Geht nicht, ein Github Pull Request enthält immer alle Änderungen des Branches. Du kannst aber einen neuen Branch erzeugen (von upstream/develop) und dann per cherry picking die gewünschten Änderungen dort rein mergen. Dann normalen Pull Reust machen.

[tuxedo]

Im Umkehrschluss heißt das:

1) Möglichst im eigenen Fork "develop" immer auf den Stand des Upstreams bringen (git fetch)
2) VOR einer (geplanten) Änderung den lokalen "develop" Branch branchen (z.B. develop_sliderfix)
3) Diesen Branch dann bearbeiten und dort dann den pull-request machen

Korrekt?

Dann muss ich mir noch noch die passenden git-Kommandos hierfür suchen oder schauen wie ich das in Netbeans mache.

[jolt]

Ganz genau! Beides kannst du auch extrem komfortabel in der GitHub Web GUI machen.

[tuxedo]

Ja, bevor ich meine änderungen in meinem develop-branch hochschiebe.

Aber: Wie mache ich auf GH einen branch von einem upstream branch? Gar nicht, oder?

[tuxedo]

So, ich glaub ich hab's jetzt einigermaßen raus. Netbeans hilft hier ungemein.

Hab die PR für den sliderfix und den sliderreadonly gestellt.