' schrieb:Warum benutze ich nun nicht immer ein FPV anstelle von einer Klasse. Damit die Daten abgelegt werden können, wird ein Anschluss für das Bild zum Schreiben und ein Anschluss für das Bild zum Lesen benötigt. Außerdem muss ich angeben welche Nummer das Bild hat, das ich lesen will, bzw. an welcher Position das Bild eingefügt worden. Damit sind zwei weitere Anschlüsse verbraucht. Dann gibt es noch den Error-Cluster rein und raus sowie wie das Enum mit dem ich die Funktionalität wähle. Jetzt will ich meine Bilddaten noch in eine Datei schreiben und brauche einen Pfad Eingang. Sind zusammen schon 8 Anschlüsse. 28 hat man maximal zur Vewrfügung. Damit wird klar, dass man FPV nicht für recht komplexe "Klassen" einsetzen kann, obwohl es die Grundanforderung der Objektorientierung "Kapselung der Daten" erfüllt.

' schrieb:@unicorn, dies hier könnte zwar unvollständige Antwort, aber eine interessante sein.
Ich denke (vermute) - solange man das FP eines SubVIs nicht aufmacht (graphische Darstellung) werden die Daten auch nicht doppelt abgespeichert. Das kann man, denke ich, leicht feststellen in dem man den Profiler benutzt.

' schrieb:Und wo kommen dann die Daten her, wenn Du das SubVI erst laufen lässt und dann das FP öffnest?
Hokus Pokus Fidibus?
Nein, aus diesem Grund werden sie eben mehrfach abgelegt.

' schrieb:..
Jupp. Mehr ist es nicht, wenn man die Ableitung nicht / die Objekte nur in einem Projekt nutzt: protected Clusters, man kommt nur über einen zusätzlichen Schritt (SubVI) wieder an die Daten ran, die man reingeschoben hat. Für "normale" Programmierung bietet das keinen Vorteil, sondern eher den Nachteil dass man sich deutlich mehr Arbeit macht als man braucht. Dass die rein gesteckte Arbeit natürlich wieder einen Vorteil haben kann, wenn man die Objekte in mehreren Projekten einsetzen kann hab ich ja oben schon beschrieben.

' schrieb:Es reichen 5 Anschlüsse aus. Ein Anschluß Enum, zweimal Error-Cluster, einmal Variant Input und einmal Variant Output. Dann hast du ein Übersichtliches FGV mit 5 Anschlüssen und es werden keine dazukommen.

' schrieb:Kann ich auch von folgendem ausgehen: Daten, die in einer Klasse liegen - ob als private oder public - werden nicht mehr (so oft) kopiert?

Wenn ich also ein größerer 2D-Array habe, das bearbeitet werden muss, dann wird das ja mit normalem DF ständig (naja sagen wir sehr oft) kopiert. Was viel Arbeit macht. Ich könnte mir durchaus vorstellen, dass, liege dieses Array als private in einer Instanz, erheblich Kopierarbeit gespart werden könnte.

' schrieb:das tröstet mich... wenn man LVOOP irgendwann vernünftig einsetzen kann wirst du sicher auch Klassen programmieren wollen, die ihre Member-Variablen speichern können. Entweder kann das dann LVOOP selber - und IMHO müsste es das eigentlich bieten, damit man von OOP sprechen kann - oder man muss es sich eben programmieren und FGVs sind dann genau das Mittel der Wahl.

' schrieb:Ja, sicherlich.

In meinem Beispiel mit 600 in etwa VGA-Bildern würde man aber immer das ganze Array holen und schon braucht LV 2*747 MB.

Außerdem verliere ich die Möglichkeit die Methoden mit den Daten in einem Objekt zu bündeln. Die Bearbeitung der Daten aus dem FGV erfolgt außerhalb des FGV und kann jetzt, überspitzt gesagt, mehrfach in unterschiedlicher Weise programmiert werden und trotzdem immer das gleiche tun. OOP versucht nun gerade das zu verhindern...

Also ein OOP FGV kann nur eine geringe Anzahl von Methoden wegen der endlichen Anzahl der Anschlüsse bewältigen. Vererbung klappt auch nicht, da ich mit Erweiterung der Klassendaten auch die Methoden überarbeiten muss. Und das müsste dann im FGV geschehen.

' schrieb:Christian, ich verstehe nicht was du da speichern willst. Members? Man hat doch Schieberegister dafür, ansonsten sind die Members ja im Wire abgespeichet.
Und ja, ich glaube in der letzten Version LV 2009 wurde noch ein Value-Referenz eingefügt, was quasi den Zugriff auf daten über eine Referenz erlaubt.