Objektorientiertes Programmieren mit LV

' schrieb:Beinahe hätten es unicorn und eq geschafft, mich auf die LVOOP-Seite zu ziehen.

Mich auch, aber ich werde mir das doch einmal genauer anschauen, scheint doch langsam brauchbar zu sein.
für diese OOP "Werbung"

Anzeige

' schrieb:Guten Morgen,

@unicorn

Interessant und danke für den Anhang. Ich werde mir das mal anschauen und gucken was ich davon übernehmen kann.

Das Beispiel muss sicher noch weiter ausgebaut werden.

' schrieb:..
Mir ist auch aufgefallen, dass bei den Stellenausschreibungen inzwischen öfters steht, dass man OO Kenntnisse in LabVIEW mitbringen sollte.
..

Ich denke, als hochrangiger Projektleiter muss man heutzutage einfach die Buchstaben OO in Stellenausschreibungen fallen lassen.

' schrieb:Wo soll man so was brauchen?! :???:Alles was mit OOP gemacht werden kann, kann mit bisherigen Mitteln schon lange gemacht werden. OOP ist nur eine andere, viel komliziertere Denkweise.

Gruß Markus

Ja, genau zurück zu den Roots. Man kann schließlich auch den Maschinecode direkt eingeben, wozu brauche ich da Assembler... Ich glaube, ich habe da noch eine ur-ur-uralte 24 Byte Relais-Speicherkarte auf dem Dachboden liegen, die wiegt so viel wie ein Netbook. Die könnte ich verleihen, solange ich mit meinem Rechenschieber arbeite...
Ende

LVOOP muss ja nicht eingesetzt werden. Es gibt viele Dinge, direkt erledigen kann. Ich hatte aber auch schon Situation in den ich dachte, hätteste man nich gleich OOP eingesetzt...

' schrieb:In meinen Projekten gibt es wirklich kein Error-Wire der nicht verbunden ist und ausgewertet wird. Ich denke das dies auch ein huter Programmierstil ist. Es ist doch kein Problem ein Error-Handler zu entwickeln und alle Error-Wire abzufangen bzw. auszuwerten.

Dann ist mein LV-Code an vielen Stellen schlechter.

' schrieb:Wo soll man so was brauchen?! :???:Alles was mit OOP gemacht werden kann, kann mit bisherigen Mitteln schon lange gemacht werden. OOP ist nur eine andere, viel komliziertere Denkweise.

Gruß Markus

Sagen wir mal viel einfachere Denkweise. Wieso versteht ihr das nicht?

' schrieb:In meinen Projekten gibt es wirklich kein Error-Wire der nicht verbunden ist und ausgewertet wird. Ich denke das dies auch ein huter Programmierstil ist. Es ist doch kein Problem ein Error-Handler zu entwickeln und alle Error-Wire abzufangen bzw. auszuwerten.

Bei mir sind sie auch alle verbunden.

' schrieb:Mich auch, aber ich werde mir das doch einmal genauer anschauen, scheint doch langsam brauchbar zu sein.
für diese OOP "Werbung"

Hätte ich nie gedacht.

Ich blicke nicht, was ich damit im Alltag soll, weil ich schon so viel mit LabVIEW gemacht habe und noch nie das Gefühl hatte, etwas ohne LVOOP nicht lösen zu können.
Wie schon mal gesagt wurde im "LabVIEW-Advanced I"-Lehrgang vom Dozenten erzählt, dass es egal ist, ob man wie bisher programmiert oder mit LVOOP. Dem einen liegt die "normale" Programmierung eher, dem anderen LVOOP.
Irgendwann werde ich einen LVOOP-Lehrgang machen. Vielleicht verstehe ich dann, wieso und vor allem wie man LVOOP einsetzt. Dann kann ich entscheiden, ob ich es weiter verwende. Bis dahin sage ich zu LVOOP.

Gruß Markus

' schrieb:Wieso versteht ihr das nicht?

(Annahme: LVOOP = OOP welches in LV integriert ist)

IMHO erleichtert LVOOP nicht unbedingt den Einstieg in OOP. Auch die Tutorials werden eher Stiefmütterlich behandelt bei NI.
Den Zugang über GOOP fand ich um einiges leichter, da dort "by reference" gearbeitet wird und nicht "by value". Die ganzen Drähte in LVOOP haben mich da mehr verwirrt, als das es genützt hätten. Auch muss man höllisch bei Drahtverzweigungen mit seinen Instanzen aufpassen!
Ich bin ein absoluter Fan von GOOP und das war meine Entdeckung des letzten Jahres!
Treiber werde ich nur noch OOP programmieren. An den Rest hab ich mich noch nicht gewagt, denn da müsste ich die komplette Framework überarbeiten....


wie wär's mit einem Icon: :proOOP:

Ich gebe dir wahrscheinlich Recht! GOOP (habe es mir irgendwann angeschaut) mag besser als LVOOP sein, nur kostet es leider zusätzlich.
Mal abwarten, NI ist, soweit ich weiß, schon dran es ByRef umzusetzen. Siehe neues Feature in LV 2009 - Data Value Reference.

Ob LVOOP oder GOOP, beides ist geil. Ich sag kurz Bescheid, wenn ich mein LVOOP-Tutorial zu Ende gemacht habe.

Da freue ich mich jetzt schon drauf.
Vielleicht kannst Du mich ja überzeugen.

Gruß Markus

' schrieb:Ich sag kurz Bescheid, wenn ich mein LVOOP-Tutorial zu Ende gemacht habe.

' schrieb:...nur kostet es leider zusätzlich.

Gibt es auch in der Community Edition (auf 5 Klassen limitiert). Aber es lässt sich sehr schön überprüfen, ob GOOP geeignet ist oder nicht.
Auch der UML-Editor der dabei ist, ist empfehlenswert! Er erstellt sogar Zustandsdiagramme von StateMachines (erkennt auch die jki-StateMachine)

Hallo,

so jetzt hab ich wieder was, was mit OO zu tun hat. Vielleicht für den ein oder anderen auch ein gutes Beispiel.

Ich habe alles ziemlich OO gebaut bis auf das Frontpanel. Und genau da harkt es jetzt.

Ich habe eine Klasse View erstellt. Als Member habe ich einige Arrays, String Elemente ... eingetragen.
Als Methoden hatte ich eigentlich vor folgende zu erstellen: Visible (true,false) , Enabled (true,false), setBGColor (Integer)

Der Ablauf hätte wie folgt sein sollen:
Ich erstelle eine Instanz von der Klasse View, lade meine Daten in das FrontPanel, setze Visible auf true, setze eine BackgroundFarbe, setze Enabled auf True.


Ziel dieses Experiments sollte es sein: Die Oberfläche für den Benutzer komplett sperren zu lassen mit einem Enabled = false, sobald etwas berechnet wird.

Bisher habe ich jedes Element über die Property auf Enabled=false gesetzt. Was unschön ist (bezüglich OO).

Problem ist, dass ich nicht weiß wie ich auf die Eigenschaften des FP zugreifen kann um z.B. die Hintergrundfarbe zu ändern/Das Panel komplett zu deaktivieren etc.

Ihr aber mit Sicherheit

LabVIEWVersion:

Danke schön

Hallo,

ich mal wieder

Ich sitze grad etwas auf dem Schlauch.

Ich habe ein Objekt von Klasse1.
Das Objekt wird in eine StateMaschine getunnelt.
Problem: Ich kriege das Objekt nicht aus der StateMaschine.

Hier wird das Objekt generiert und in Zustand A getunnelt. Es soll weiter in Zustand B getunnelt werden. Damit man das "verränderte" Objekt aber weiterleitet, muss man so eine Rückkopplung haben.
   

Hier ist jetzt das Problem. Ich möchte, dass das Objekt nun an die Ausgangsklasse geleitet wird, so dass ich es z.B. in einem anderen VI weiterverarbeiten kann.
Das geht nicht. Die Fehlermeldung sagt, weil es sich um ein dynamisches FP Element handelt kann ich das so nicht machen.
   


Hat jemand eine Lösung?

Danke
LV Version: 8.6
Update: Bilder geupdatet.Hatte sich ein Fehlerteufel eingeschlichen. 18.08; 10.35h