LVOOP im Kommen!

' 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.

Wenn du nun aber in einem Entwicklerteam arbeitest weiß das vielleicht nicht jeder Programmierer

' 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.

Wann warst du denn da? Genau von dieser Schulung hab ich doch die Infos.

' 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.

Gibts schon. musst aber nach Amerika

Anzeige

Letztes Jahr im Frühjahr. Und Du?

Gruß Markus

' 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

Letzte Woche

Vielleicht hat die Marketingabteilung von NI dazu aufgerufen, dass genau das jetzt in den Schulungen gepredigt wird.

Gruß Markus

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.
   

Grüße
Götz

' 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

OHA! DAS sieht ja spannend aus

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: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

Kannst du mal ein Beispiel posten?

' schrieb:Kannst du mal ein Beispiel posten?

Nein, das darf ich leider nicht.

' schrieb:Nein, das darf ich leider nicht.

War voraus zu sehen.

Mir ist noch ein Grund eingefallen, warum man (LV)OOP machen sollte: Durch OOP wird es nämlich praktisch unmöglich, mal schnell so zwischenrein den Sourcecode "anzupassen". Oft möchte der Kunde ("plötzlich") ein neues Feature. Dann ist der Programmierer ohne OOP dazu verleitet: "Ach guck, da oben rechts am FP ist noch klein bischen Platz. Und im BD, das ziehen wir auf, machen wir noch ein SR (zu den mittlerweile 18 anderen) und das mit den Wires bekommst du ja auch noch hin". Und ruckzuck hat man ein BD wo nur noch ich mich auskenne.

Mit OOP geht das nicht mehr (so einfach). Da müssen neue Features - wie es sich halt gehört - in die Klasse "gequetscht" werden. Vorteil: Das FP bleibt (oder wird wieder) sauber - genau so das BD (respektive die vielen SubVI-BDs).

OOP verhindert also so ganz nebenbei unstylische Programmierung. (Was natürlich wieder nicht heißt, dass man nicht auch ohne OOP stylisch programmieren kann.)