Fragen und Probleme mit Edomi unter CentOS 6

[sipiyou]

So, ich hab den Fehler gefunden.

Davon sind wahrscheinlich auch diverse andere Clickevents betroffen, denn mir ist auch aufgefallen, dass meine Buttons in der Visu träger reagieren bzw. der "Klick" nicht registriert wird.

Das Problem ist der onDown-Flag, dieser wird mit 2.0 nicht gesetzt und genau das führt dazu, dass das Klickverhalten wesentlich träger wie 1.64 ist und zwischendurch schnelle Klicks verloren gehen.

d.h. für "altes Klickverhalten" bei der Pineingabe muss in der

/usr/local/edomi/www/data/liveproject/vse/vse_include_visu6.js

visuElement_onClick(document.getElementById("e-"+elementId+"-k1"),function(veId,objId){VSE_24_virtualKey(veId,1 );},((obj.dataset.var4&1)?true:false));

einfach durch

visuElement_onDown(document.getElementById("e-"+elementId+"-k1"),function(veId,objId){VSE_24_virtualKey(veId,1 );},((obj.dataset.var4&1)?true:false));

ersetzt werden.

Alternativ kannst du, wenn du irgendwann onDown wegoptimieren möchtest den forceDownEvent auf "true" setzen. Was es bewirkt, hab ich mir jetzt nicht angeschaut.

Ich würde es begrüssen, wenn du dadraus einen offiziellen Patch bastelst und auch das Verhalten der anderen Events dir anschaust. Es wundert mich allerdings sehr, dass es sonst keinem aufgefallen ist, denn es ist definitiv ein Codeproblem und ich habe hier momentan noch eine 0815 Visu.

Soviel zu meinem eigentlichen Vorhaben, den Gira-HS in die Tonne zu treten, weil ich nicht selbst das Rad bei jeder Kleinigkeit erfinden wollte und einfach mal "Nutzer" sein wollte.

[gaert]

Hä? Diese 2 Funktionen sind schon jeweils in Ordnung und haben ihren Sinn. Bei mir funktioniert's ohne Probleme...

Was Du da "patchst" umgeht einfach die Visu-Account-Einstellungen des Nutzers - dies ist aber nicht Sinn der Sache.

[sipiyou]

Ja, du hast recht. Der Fehler steckt weiter vorne, zumal die von mir genannte Datei jedesmal bei einer Projektaktualisierung neu generiert wird.

Ich hatte nur "das Ende" gefunden, allerdings hatte ich mir deinen Code auch nur oberflächlich angeschaut.

Anbei 2 Bilder mit der initialisierung mit onClick und onDown. Einziger Unterschied ist, dass der EventListener mit

downEvent (= "touchstart") initialisiert wird (bei onDown).

Wird der EventListener mit "Click" initialisiert, so geht gibt es das Problem.

Als dritte Datei ist die Initialisierung (clickEventInit.png). Dort wird der downEvent auf "touchstart" gestellt, aber der clickEvent auf "click", ungeachtet dessen, ob es sich um ein "Touch" oder "Maus" handelt und hier liegt letzendlich auch das Problem.

D.h. bei mir gibt es einfach ein "click"-Event Problem, dieses Problem gibt es sowohl mit den beiden Android Tablets (Chrome & Fully), wie auch mit dem Ipad Pro (Safari).

Dass das Problem bei Dir nicht auftritt, glaube ich dir fast nicht, stell zum testen den click auf touchstart und dann geh ganz schnell über das Tastenfeld des Keypads.
Selbst auf dem Ipad merkst du einen deutlichen Unterschied zu click. Das gleiche gibt es auch bei Buttons, nur da fällt es in der Regel nicht so auf, weil man eh nur ein Feld anklickt.

Falls du zum beheben des Fehlers noch mehr Input brauchst, werd ich dir das zur Verfügung stellen, aber ich kann dir keine Lösung jetzt geben, da ich aus der C/C++ Welt komme; ich kann zwar dutzende Programmiersprachen, aber so tief kenne ich mich in Javascript nicht aus, dass ich Dir adhoc weiterhelfen kann, hier müsste ich mich selbst einlesen und abgesehn davon ist es dein Code, wo ich nicht irgendwas dran ändern will.

/edit:

Zum Testen:

/usr/local/edomi/www/visu/include/js/main.js

Zeile 133

clickEvent='click';

ändern auf

clickEvent='touchstart';

/edit2: Unter den Visu-Account Einstellungen sollte dann der

Klickmodus auf "beim Loslassen"
Eingabegerät "Touch-Bedienung"

gestellt werden. Hatte eben noch das Problem beim Display oben, nun läuft es flüssig.

[gaert]

Ah ja...! Du hast Recht - ich hab's offenbar nie mit Codeschloss+iPad getestet. Nur Deine Lösung ist nicht ganz korrekt, bzw. nicht im Sinne des Erfinders.

Ersetze mal einfach die komplette JS-Funktion setInputMode() wie folgt:

function setInputMode(touch,click,scroll) {
    if (touch==2 || (touch==0 && ('ontouchstart' in window))) {
        visu_touchMode=true;
        downEvent='touchstart';
        moveEvent='touchmove';
        upEvent='touchend';
        cancelEvent='touchcancel';
        clickEvent='touchstart';
    } else {
        visu_touchMode=false;
        downEvent='mousedown';
        moveEvent='mousemove';
        upEvent='mouseup';
        cancelEvent=false;
        clickEvent='mousedown';
    }

    if (click!=0) {
        clickEvent='click';
    }

    if (scroll==0) {
        document.body.style.position="fixed";
    } else if (scroll==1) {
        document.body.style.position="absolute";
    } else if (scroll==2) {
        if (!visu_touchMode) {document.body.style.position="absolute";} else {document.body.style.position="fixed";}
    } else if (scroll==3) {
        if (visu_touchMode) {document.body.style.position="absolute";} else {document.body.style.position="fixed";}
    }
}

[sipiyou]

Wie schon gesagt, das Problem fällt nur beim Codeschloss "wirklich" auf, das Problem gibt es aber auch bei allen Buttons, da hat man das Gefühl, dass das Eingabegerät kaputt ist.

Danke für den Patch, aber es löst das Problem immer noch nicht.

Das Problem ist immer noch click != 0, denn click = 1 und das überschreibt wiederrum den clickEvent. Im Screenshot clickEventInit.png siehst du, dass bei mir setInputMode mit click=1 initialisiert wird.

Kann es sein, dass ein click nur im Maus-Modus sinn macht ? Ich hatte gestern mir noch die Eventreihenfolge angeschaut, der click Event ist an letzter Stelle der Eventauswertung im JS-Handler.

Beim Touchscreen wäre es doch sinnvoller, den Klick per default beim loslassen auszuwerten ?

[gaert]

Das Click-Event wird auch bei Touch-Geräten laut Webkit-Spezifikation korrekt ausgewertet. Je nach OS verhält sich das aber unterschiedlich - iOS wartet z.B. 300ms bis das Event feuert, um einen "Longklick" zu unterscheiden (bei iOS führt dies zur Selektion/Kontextmenü).

Und ich hab's jetzt ja auch getestet (iPad/iMac) - funktioniert. Getestet mit Codeschloss und einem normalen Button (Universalelement). Nach dem Patchen musst Du natürlich den Browser-Cache löschen, damit das neue Script "greift".

[sipiyou]

Ich habs eben nochmal auf dem Ipad getestet, es ist in der Tat auf dem Ipad jetzt in Ordnung, jedenfalls fällt es nicht mehr ins Gewicht.

Aber das Problem besteht bei den Android-Geräten immer noch. Sobald onClick verwendet wird ist es träge.

Wofür benötigst du den onClick Event auf einem Touchdisplay überhaupt ? Selbst bei einem longClick verwendest du den downEvent und nicht den clickEvent. visuElement_onClick:

if (functionShort && !functionLong) {
obj.addEventListener(((forceDownEvent)?downEvent:c lickEvent),function(){
if (checkClick()) {
if (indicateShort) {visuElement_indicate(document.getElementById(objI d));}
functionShort(veId,objId);
}
},false);

} else if (functionLong) {
obj.addEventListener(downEvent,function(){
if (checkClick()) {
longClick(veId,objId,functionShort,functionLong,in dicateShort,indicateLong,animationLong);
}
},false);
}

[gaert]

Weil die Spezifikation es so will - ein Klick ist ein Klick und das OS entscheidet, was ein Klick ist Klar kann ich mir auch einen eigenen Klick-Handler bauen, aber wozu?

[sipiyou]

Alles, was ich finde ist, dass auf einem Touch-Display clickEvents zu unnötigen Verzögerungen führen, die vom Benutzer als störend empfunden werden können.

Du musst keinen eigenen clickHandler implementieren sondern auf Touchgeräten nicht click, sondern touchstart verwenden.

Hier ein paar Links zum stöbern (die Googlesuche gibt noch mehr).

https://coderwall.com/p/bdxjzg/tap-v...h-by-ignorance

^ Ironischerweise würde die Überschrift langsam auch hier zutreffen "Click death by ignorance"

https://stackoverflow.com/questions/...-devices-in-js
https://www.mediaevent.de/javascript/touch-events.html

Um es kurz zu machen, folgender Code würde das Problem auch auf den Android-Geräte fixen:

/edit: nochmal mit richtigen newlines...

 function setInputMode(touch,click,scroll) {
    if (touch==2 || (touch==0 && ('ontouchstart' in window))) {
        visu_touchMode=true;
        downEvent='touchstart';
        moveEvent='touchmove';
        upEvent='touchend';
        cancelEvent='touchcancel';
        clickEvent='touchstart';
    } else {
        visu_touchMode=false;
        downEvent='mousedown';
        moveEvent='mousemove';
        upEvent='mouseup';
        cancelEvent=false;
         clickEvent= (click != 0) ? 'click' : 'mousedown';
    }
      if (scroll==0) {
        document.body.style.position="fixed";
    } else if (scroll==1) {
        document.body.style.position="absolute";
    } else if (scroll==2) {
        if (!visu_touchMode) {document.body.style.position="absolute";
    } else {
        document.body.style.position="fixed";}
    } else if (scroll==3) {
        if (visu_touchMode) {document.body.style.position="absolute";} else {document.body.style.position="fixed";}
    }
}

[powell]

Hi, ich habe deinen Code gerade mal getestet und die Code Eingabe läuft bei mir damit auch flüssiger. Danke fürs teilen!

[MrIcemanLE]

Hallo Zusammen,

ich habe heute auf 2.0 aktualisiert. Danach musste ich feststellen, dass meine Benutzer-CSS-Eigenschaften nicht mehr funktionieren. Ich hatte bisher die Icons auf meiner Startseite auf 70% reduziert. Nach dem Update werden diese aber in voller Größe angezeigt. Kann das Verhalten jemand bestätigen oder ist das ein Cache-Problem?

Kann ich bestätigen! CSS Hintergründe schauen bei mir jetzt auch anders aus.

gaert Christian, kannst du das Problem mit den Hintergründen nachvollziehen? Würde mir sonst irgendwie anders helfen.

Gruß
Stefan

[gaert]

sipiyou
Ja klar, aber damit wird ja kein Klick registriert sondern ein touchstart... Genau das will ich nicht. Wenn der User "Klick" wählt, soll er auch Klick bekommen

[gaert]

Was die Hintergründe betrifft: Ist halt so

In 2.0 werden die Eigenschaften anders zugewiesen als zuvor, somit ist ein Überschreiben der von EDOMI gesetzten CSS-Eigenschaften nicht immer möglich. Dafür ist das Feld übrigens auch nicht gedacht! Hier kann man ergänzende(!) Eigenschaften angeben, die vom Design-Dialog nicht abgedeckt werden.

[starwarsfan]

Hallo miteinander,

also ich kann mich des Eindruckes nicht erwehren, dass gaert und sipiyou irgendwie aneinander vorbei reden...

[sipiyou]

gaert
Ich bin nochmal etwas tiefer eingestiegen; dein Patch funktioniert. Mein Fehler war es, dass ich die Definition von "Klickmodus" falsch verstanden habe.

Ich hatte unter Visueinstellungen den Klickmodus auf "Beim loslassen".

Wenn ich die Option Klickmodus auf "beim betätigen" ändere und deinen Code oben verwende, dann wird der clickEvent nicht mit "click" überschrieben.

Das ändert aber nix an der Tatsache, dass ein click beim einem Touch keinen Sinn ergibt. Aber so läuft es und der Rest soll mir egal sein

starwarsfan : Danke Dir für den kleinen Tritt