' schrieb:Hmm, und was machst du z.B. wenn du den Inhalt eines Members aufs FP ausgeben willst? Du musst es doch nach aussen ausgeben oder nicht?
na, was macht man? man schreibt sich eine Methode, die die Members als Daten ausgibt. Wenn du jetzt ein Control von einem Objekt-Draht erzeugst, dann siehst du ein 3D Kästchen ... mehr nicht
- wenn du außerhalb des Objektes ein Unbundle anschließt bekommst du lediglich einen "broken wire" ... mehr nicht ...
Um das nochmal ganz deutlich zu sagen: der "Objekt Draht" AUSSERHALB des Objektes ist IMHO unnötig, nicht der innerhalb der Methoden-VIs ...
' schrieb:@ i2dx: Das ist eigentlich keine schlechte Idee: Die Daten eine Klasse liegen gekapselt in der Klasse und man kann in jeder Methode daraufzurück greifen und man braucht sie außerhalb der Klasse nicht durch einen Draht bewegen.
Allerdings widerspricht das der LV-Philosophie und man handelt sich leicht race-conditions ein, weil die Reihenfolge der Klassen-VI nicht per se durch den Draht des Klassenobjekts festgelegt ist.
für den Erhalt des Datenfluss-Modells reicht doch der Error-Cluster. Race Conditions sind per se ausgeschlossen, weil die Methoden immer noch VIs sind und die werden nicht parallel abgearbeitet sofern sie nicht reentrant sind ...
