' schrieb:Hab ich gesehen. Wenn du sagst, das geht, reicht mir das - vorerst.

Stimmt.
Aber: Wer lässt denn lesen? Nicht das VI. Der Programmierer! Der baut nämlich sein Programm auf. Und wenn der weis, dieses VI gehört dieser Klasse, und es trotzdem anders verwendet - ist der Programmierer Schuld. Nicht das VI. Eine FGV kann zwar von anderen VIs gelesen werden - wird aber nicht, weil der Programmierer nicht will.

' schrieb:Wenn ich das alles so lese, bin ich froh, dass ich mit meiner Meinung nicht alleine dastehe.
So wie id2x und IchSelbst (und auch ich nach Bedarf) verfahren, so wird es bei NI auch bei den Schulungen beigebracht.
Und wie (in einem anderen Thread) schon mal gesagt, wird LVOOP nicht mal vom Referenten des Advanced 1 - Lehrgangs verwendet.

' schrieb:Dort wurde uns gesagt, dass man zwar LVOOP verwenden kann, aber das ALLES auch mit den "normalen" LabVIEW-Programmiermethoden erreicht werden kann. LVOOP ist im Prinzip nur eine Spielerei, die man verwenden kann, aber nicht muss, weil es problemlos auch anders geht.
Und wieso sollte man sich in irgendwas einarbeiten, wenn man das andere schon kann.

Gruß Markus

EDIT: Interessehalber werde ich mir aber vielleicht trotzdem mal die neue Schulung zu LVOOP anhören, die ja offensichtlich geplant ist. Vielleicht gibt es sie aber auch schon.

' schrieb:Wenn du nun aber in einem Entwicklerteam arbeitest weiß das vielleicht nicht jeder Programmierer
Wann warst du denn da? Genau von dieser Schulung hab ich doch die Infos.

Gibts schon. musst aber nach Amerika

' schrieb:Letztes Jahr im Frühjahr. Und Du?

Gruß Markus

' schrieb:Servus...

ist schon spät deshalb nur kurzer Hinweis zum Testcode von i2dx. Ich vermute das der Ansatz unter LV 8.6.1 tatsächlich nicht funktionieren kann. Da fehlt die entscheidene Funktion die erst in 2009 hinzugekommen ist.
[attachment=53745:preserve...me_class.jpg]

Grüße
Götz

' schrieb:Servus nochmal...

Zur erwähnten Aussage des LV Advanced I Referenten (das war wahrscheinlich mein Kollege oder ich, zumindest wenn es in den letzten Jahren war) über LVOOP. Das hat sich in der Zwischenzeit geändert :-)
Inzwischen benutzen wir LVOOP standardmäßig in neuen LV-Projekten. Im Moment nutzen wir LVOOP darin hauptsächlich zum einfacheren, statischen Anlegen/Duplizieren von Programmmodulen. Diese sind dann selbst wiederum als (Producer +) Consumerschleife mit MessageQueue ausgeführt. Die Messages selbst sind zur Zeit noch der "übliche" Cluster aus Command (Enum) und Daten (Variant), so wie es auch im Kurs beschrieben ist. Grund dafür ist, daß wir noch 8.6.1 unterstützen wollten (in dem ja die "Preserve Run-Time Class" Funktion noch fehlt) und den Umstieg von unseren älteren Applikationsvorlagen zu erleichtern. Das wird vielleicht irgendwann einmal ersetzt durch Messages, die selbst LVOOP-Objekte sind.
Wohin die Reise bei den Basisarchitekturen bei uns genau geht, ist noch nicht ganz klar, aber meine Prognose ist, daß der LVOOP-Anteil dabei stetig steigen wird.

Grüße aus München
Götz

' schrieb:Kannst du mal ein Beispiel posten?

' schrieb:Nein, das darf ich leider nicht.