Gern geschehn. ^_^
PS:
' schrieb:...Wenn man es aber so macht wie vorgeschlagen, dann könte man noch einen Schritt weiter gehen und auf den Selektor Init/Read/Write ganz verzichten...
Das werd ich mir mal anschauen wenn ich Zeit hab. Dann wirds aber nen optionalen boolschen Eingang geben zum Zurücksetzen der FGV.
Was mich jetzt noch stört (naja nicht wirklich, aber ich bastel ja sogerne) ist, dass man für das bundle by name erst eine Konstante vom Eingangscluster erzeugen muss. Hat da einer ne Idee oder ist das dann halt so?
Gruß SeBa
' schrieb:Also hier liegst Du entweder ganz falsch oder ich versteh nicht wie Du das meinst.
Ja, wir reden bzw. schreiben aneinander vorbei.
Ein typisches FGV enthält bei mir eine Case-Struktur und eine Enum, mit der ich die Funktion des FGV auswähle, die ich ausführen will:
Hier A setzen:
[
attachment=22684]
Hier B setzen:
[
attachment=22685]
Funktion A+B:
[
attachment=22686]
etc. etc.
Jeder Fall hat somit eindeutig definiert, welche Eingänge benötigt werden.
Gruß, Jens
' schrieb:Was mich jetzt noch stört (naja nicht wirklich, aber ich bastel ja sogerne) ist, dass man für das bundle by name erst eine Konstante vom Eingangscluster erzeugen muss. Hat da einer ne Idee oder ist das dann halt so?
Ich mache das einfach so. daß ich nur am Anzeigecluster die Elemente mit Namen versehe und an das Bundle einfach eine lokale Variable dieses Clusters anschließe. Das Anzeigeelement sollte dann, falls die Elementwerte bei der Initialisierung überhaupt eine Rolle spielen, diejenigen Werte als Standard gespeichert haben, wie sie sonst in der Konstanten enthalten wären.
' schrieb:Ja, wir reden bzw. schreiben aneinander vorbei.
So wie Du es jetzt erklärst ist es schon klar. Nur zielte die ursprüngliche Frage, die den ganzen Thread ausgelöst hat, gerade darauf ab, wie man dem FGV-VI beibringen kann, daß es allein am fehlenden oder nicht fehlendem Draht am Dateneingansananschluß mitbekommt, ob hier aus dem VI nur gelesen oder auch eingeschrieben werden soll. Oder mit anderen Worten: Wie man diesen Selektoranschluss, der dem VI genau das sagt, einsparen kann. In Deiner Antwort erwähnst Du den Selektoranschluß nicht. In in Deiner jetzigen Klarstellung stellt sich geraus, daß Du den als selbstversändlich vorausgesetzt und nicht zur Disposition gestellt hattest. Das konnte man aber wegen der etwas anders gestellten Frage so nicht automatisch vermuten.
Gruß Ludwig
Ich habe es wie JensG verstanden. Lucki, die von dir skizzierten Möglichkeiten der VI-Anpassung (sie stehen auch dir zur Verfügung, allerdings nur während der Development-Time und nicht zur Runtime) verändern den Code eines VIs und führen damit eine FGV ad absurdum. Mann bräuchte zur Fallunterscheidung nicht einmal je einen Case je Fall, sondern ein simpler Algorithmus, der bei 8 Eingangwerten mit einem U8 oder einem Boolarray zur Informationsübergabe der gesetzten Eingänge gefüttert wird wäre genug der Arbeit.