[HTML / Javascript @iPad ] Button disablen VOOR HttpRequest

[Atmoz]

Beste allemaal,

Het begon als een "ah, dat heb ik zo gefixt", maar is inmiddels uitgelopen tot een meerdere uren "project" Tijd om de hulp van Tweakers in te schakelen dus

Ik heb een formulier met enkele knoppen erop. Één daarvan moet data ophalen uit een PHP script, en dit in een variabele zetten voor verdere verwerking.

Om die data op te halen uit die PHP gebruik ik onderstaande functie:

code:

function httpGet(theUrl){
  xmlhttp = new XMLHttpRequest();
  xmlhttp.open("GET",theUrl,false);
  xmlhttp.send(null);
  var fileContent = xmlhttp.responseText;
  return(fileContent);  
}

Vóór ik die functie aanroep doe ik netjes:

code:

document.getElementById('btnTest').disabled = true;

En zodra de functie klaar is (data is netjes binnengekomen na een paar seconden) zet ik 'm weer op false. So far so good. Alles werkt

Behalve op de iPad wat hier voor me ligt

Wat ik ook probeer... de button wordt pas gedisabled NA het runnen van die functie. Wat dus betekend dat de gebruiker 10x op die knop kan drukken, waardoor er 10 aanvragen achter elkaar worden gedaan. De gebruiker denkt dat het sneller gaat zodra hij/zij er meerdere malen op drukt, maar het wordt er uiteraard alleen maar trager van

Heb ook met jQuery gestoeid, met "setTimeout", met PHP, etc...
Niets lijkt te werken. Zelfs een variabele (working=true) zetten en bij de volgende keer de functie aanroepen checken wilt niet werken. Ik kan nog steeds meerdere aanvragen achter elkaar initiëren aangezien die knop niet (op tijd) gedisabled wordt op de iPad.

What 2 do? Er moet toch wel iets te verzinnen zijn waardoor het ook op de iPad werkt?
Ik sta open voor de gekste oplossingen, zelfs niet gangbare "omwegen" zouden helpen. Als 't ding maar gaat werken zodat men niet meerdere (onnodige) aanvragen achter elkaar kan doen.

Thanks voor het meedenken

[Juup]

Maak de XHR asynchroon.
Je krijgt nooit de garantie dat DOM operaties onmiddellijk worden uitgevoerd.
De browser mag dat zelf bepalen. In jouw code blokt de synchrone XHR de DOM actie.

[ Voor 91% gewijzigd door Juup op 13-01-2016 15:03 ]

[Atmoz]

Juup schreef op woensdag 13 januari 2016 @ 15:00:
Maak de XHR asynchroon.
Je krijgt nooit de garantie dat DOM operaties onmiddellijk worden uitgevoerd.
De browser mag dat zelf bepalen. In jouw code blokt de synchrone XHR de DOM actie.

Thanks!
Ik ben er inderdaad op die manier uit gekomen

Dju, had ik maar iets meer verstand van dit soort zaken, dan had ik me wat uren kunnen besparen

[ViNyL]

Heb je ook dit al eens geprobeerd? In plaats van je request aanpassen?

code:

       document.getElementById('element').setAttribute("disabled","disabled");
       document.getElementById('element').removeAttribute("disabled");

[R4gnax]

ViNyL schreef op woensdag 20 januari 2016 @ 15:56:
Heb je ook dit al eens geprobeerd? In plaats van je request aanpassen?

code:

       document.getElementById('element').setAttribute("disabled","disabled");
       document.getElementById('element').removeAttribute("disabled");

Komt op hetzelfde neer als de disabled property: geen garantie dat de DOM aangepast wordt voordat een synchrone XmlHttpRequest alles blokkeert. Enige juiste oplossing hier is om een (standaard) asynchrone XmlHttpRequest te gebruiken.

Trouwens; binnenkort gaat ondersteuning voor synchrone XmlHttpRequests op de UI thread überhaupt toch vervallen. Dan zul je er ook aan moeten geloven; of je nu wilt of niet. Beter om het nu al gecontroleerd goed te doen.