Reihenfolge des Codes verdreht.

[tsseh]

Dann ich wieder das gleiche Problem wie am Anfang.

es gibt kein problem, es gibt callbacks

Und ich kann das Brot nicht essen, bevor es geschnitten ist.

und deswegen iss es, wenn dir gesagt wird, es ist geschnitten

 

[Mathias1000]

und deswegen iss es, wenn dir gesagt wird, es ist geschnitten

Das habe ich auch schon probiert.

var geladen = false;

function loadByteBuffer(file) {

    var byteBuffer;

    var reader = new XMLHttpRequest();
    reader.open("GET", file, true); // geht

    reader.onreadystatechange = function () {

        console.log('onLoad');

        if (reader.readyState == 4) {
            console.log(reader.responseText);
            geladen = true;
        } else {
            console.log('Fehler');
        }
    };
    reader.send();

}

loadByteBuffer("shader/monoColor.frag");
while (!geladen) {
    console.log('Versuche zu laden');
}
console.log('Laden erfolgreich');

Nur bekomme ich so eine Endlosschleife.

 

[tsseh]

Das habe ich auch schon probiert.

das ist aber auch unfug, der code eines js-eventhandler bzw. der "main-code" der beim start ausgeführt wird, wird immer vollständig abgearbeitet, ehe der nächste eventhandler (wieder vollständig) ausgeführt wird. js hat (von workern mal abgesehen) nur einen thread. onreadystatechange kommt also nie drann, weil du im main-teil darauf wartest, daß geladen auf true geht, was aber nur im onreadystatechange passieren kann, was nicht drann kommt
DESWEGEN GIBT ES CALLBACKS/EVENTHANDLER
du stehst vor der brotschneidemaschine, mit welcher jemand dein brot schneiden soll und wartest darauf, dass diese dir saght es ist geschnitten. derjenige der dein brot schneiden soll kommt aber nicht ran, da du sie blockierst.

 

[Dormilich]

noch eine Anmerkung da du von Java zu kommen scheinst.

Zwischen JavaScript und Java gibt es genau eine Gemeinsamkeit: die 4 Buchstaben "Java".

Ansonsten funktioniert JavaScript komplett anders als Java, also versuch gar nicht erst, etwas, was du in Java kennst eins-zu-eins zu übernehmen.

 

[Mathias1000]

Eigentlich ist meine Muttersprache Pascal, Java ist bei mir auch sekundär.
Ursprüglich war es GW BASIC.

 

[Dormilich]

soweit ich weiß ist auch Pascal keine Event-basierte Sprache. (genaugenommen sind die Events eigentlich kein Feature der Kern-Sprache /1/, sondern des JS-Environments. Obwohl mir jetzt auch kein Environment bekannt ist, das das nicht bietet)

/1/ - siehe auch https://developer.mozilla.org/en-US/docs/Web/API

 

[tsseh]

du sagst es ja selbst, callbacks sind ein pattern (klingt blöd, also dass prinzip der callbacks gehört zu den entwurfsmustern) und kann in jeder sprache angewendet werden. wenn einem das bisher nicht untergekommen ist, muss man sich damit beschäftigen. in js ist das alles noch einfach, kein multithreading, keine reentrance und ich habe keine ahnung, was daran so schwer sein soll, ist etwas fertig, wird eine funktion gerufen. gut is.

 

[Mathias1000]

Gibt es vielleicht eine direkte/andere Variante Daten einzulesen als mit onreadystatechange ?

Etwas auf diese Art ?

function loadByteBuffer(file) { 

    var reader = new XMLHttpRequest(); 
    reader.open("GET", file, true);

    console.log(reader.responseText); 

    reader.send(); 
} 

loadByteBuffer("shader/monoColor.frag"); 

console.log('Laden erfolgreich');

 

[tsseh]

Gibt es vielleicht eine direkte/andere Variante Daten einzulesen als mit onreadystatechange ?

und was soll mit dem ergebniss des lesens passieren? stellt sich diese frage nicht sofort? also, nein. und nochmal du liesst nicht, du lädst runter, vom server, das dauert mal 1 min, mal 1 sec, mal 10 sec. und mal 10 tage. sowas macht man asynchron. man liest solange bis man alles hat und am ende übergibt man das ergebniss dem callback. selbst beim lesen von platte sollte man das eigentlich so machen.

 

[Mathias1000]

und was soll mit dem ergebniss des lesens passieren? stellt sich diese frage nicht sofort?

Die Daten werden für WebGL gebraucht.
Die meisten sind Vertex-Daten, welche ich zur GPU kopiere, bei denen kann ich leben, wei die Daten später kommen.
Aber beim Shader-Daten sieht es anders aus, die muss ich sofort haben, ansonsten habe ich einen Shader-Link Fehler. Momentan befinden sich der Shader-Code in der HTML-Datei, ich würde sie lieber als Extra-Datei haben.

 

[tsseh]

du kannst die shaderdaten auch als script einbinden, aber nein, du du benötigst sie nicht sofort, sondern kannst sie auch erst laden