Danke für dein Feedback GPI.
GPI hat geschrieben:Eventuell sind die Rahmen die falsche Methode für "IF" "CASE" etc.Ich kenn das in Diagrammen, das man hier eine Raute nimmt. In die Raute die Frage und dann seitlich "ja" und "nein" weg.
Du meinst
Flussdiagramme. Das ist von der Sache schon richtig, allerdings soll die Oberfläche kein Flussdiagramm darstellen, sondern ehr sowas wie ein
Blockdiagramm.
GPI hat geschrieben:Die Frage ist halt wirklich, worauf die genau hinaus willst. Bei deinen Beispiel auf der ersten Seite werden ja alle "Bäume" gleichzeitig berechnet.
Korrekt, und das ist auchgewollt bzw. beabsichtigt. Solange zwei oder mehr "mini"-Codes (wie das Erzeugen von diesem Sinnlosen Datum und die beiden anderen Berechnungen) nicht von einander abhängig sein (in Form von Daten), können/dürfen sie ja gleichzeitig ausgeführt werden. Natürlich macht das bei einer Ausgabe wenig sinn, bei einer komplexen Funktion mit z.B. 5 Eingängen und 5 Ausgängen dagegen schon, wenn die Funktion ihre Arbeit teilweise automatisch paralelisiert.
Bei den Ifs und Cases die ich gerade baue, ist es nun so, dass außschließlich einer der Rahmen überhaupt nur ausgeführt wird, wenn die jeweilige Zuordnung zutrifft. Zum Beispiel wird esspäter ein "ReadFile" Knoten geben (mit Pfad-Eingang und Referenz-Ausgang). Aber nur wenn die Datei gelesen werden konnte, wird dann der Rahmen ausgeführt, wenn gelesen werden kann, ansonsten der andere Rahmen (zB. mit einem MessageRequester-Knoten)
GPI hat geschrieben:Eventuell wäre ein "Switch/gate" die bessere Lösung. Zwei Eingänge. einen WERT, der ohne Typumwandlung weitergeleitet wird und einen "Power" eingang. Wenn ein Wahr an Power liegt, wird der Wert 1:1 übertragen, ansonsten endet der Baum.
Ich weis nicht ob wir das selbe meinen, meine Idee dazu wäre: ein "Boolean"-Eingang (dein power) und zwei Werte-Eingänge für den True und False Fall. Je nach Zustand wird dann entwederder eine oder andere Wert weiter geleitet.
GPI hat geschrieben:Achja: Eventuell eine gute Idee, die Linien je nach Typ anders zu zeichen. Durchgehend ist Zahl, gestrichelt Strings.
Jo hatte ich auch schon überlegt. Aktuell sind die Typen nur farblich zu unterscheiden, weil ich gestrichelt für "kaputte" Verbindungen nutzen wollte (wenn die Typen nicht passen oder so). Strings zu straffieren oder dicker zu machen wäre aber sinnvoll, da ja "mehr" transportiert wird. Arrays sollen später zB Doppellinien bekommen (je nach Dimension).
Ich gebe zu, es ist vermutlich noch schwer zu sehen, wo das ganze hinführen soll, da das wichtigste ja noch komplett fehlt, nämlich die Ein- und Ausgabe nach "außen" z.B. über Gadgets.