Eigenschaftsknoten von beliebigem Control

Hallo,

also ich habe wohl eine recht einfache Frage. Ich kann einen Eigenschaftsknoten erstellen und diesem die Referenz von einem x beliebigem Control übergeben. Ich kann aber auch explizit zu diesem Control gleich einen Eigenschaftsknoten erstellen, diesem ich dann keine Referenz zu übergeben brauche.
Worin liegt programmiertechnisch der Unterschied zwischen den beiden Knoten?

Dem einen übergebe ich die Referenz des Controls

Ist der andere Knoten ein Objekt des Controls? Ähnlich wie in C++ ein Objekt einer Klasse?

Anzeige

Hallo Wendigo,

Zitat:Worin liegt programmiertechnisch der Unterschied zwischen den beiden Knoten?

Den einen kannst du nur im VI verwenden, in dem sich auch das Control befindet, den anderen in jedem beliebigen VI!
Der Compiler sollte aus beiden den gleichen Code erzeugen...

Das mit der Anwendung ist mir klar

Hat das denn was mit Vererbung zu tun? Das Ganze muss ja irgendwie begründbar sein.

Hallo Wendigo,

das hat nichts mit Vererbung zu tun.

Es geht einzig um die Frage, wie die Referenz für die PropertyNode bereitgestellt wird: explizit (per Draht) oder implizit (per Verlinkung mit einem Control, wie man sie auch im Kontextmenu der PropertyNode aufrufen kann...)!

In beiden Fällen arbeite ich also mit der gleichen Referenz. Dabei muss der Zugriff auf diese Referenz total unterschiedlich sein.
"Das eine ist verkabelt, das andere nicht" ist doch keine wirkliche Erklärung.

Wesentlich mehr als was Gerd schon geschrieben hat gibt es aber nicht.

Also nochmal:
- Die direkte PropertyNode/InvokeNode kannst du NUR in dem VI anwenden, in dem das entsprechende Control existiert.
- Eine Referenz kannst du z.B. an ein SubVI übergeben, um dann in diesem SubVI die Eigenschaften oder Methoden zu ändern.

Und jetzt noch eine Ergänzung:
Ganz unrecht hast du mit Klassenhierachie nicht, denn mit den beiden Funktionen "To More Generic Class" und "To More Specific Class" kannst du schon eine Referenz allgemeiner bzw. genauer abändern.
Das ist z.B. hilfreich, wenn man sich per PropertyNode alle Referenzen aller Controls des FPs holt. Die haben nämlich anfangs nur die Klasse "Control".

Gruß, Jens

Anzeige

(08.01.2013 12:41 )jg schrieb:  Wesentlich mehr als was Gerd schon geschrieben hat gibt es aber nicht.

Also nochmal:
- Die direkte PropertyNode/InvokeNode kannst du NUR in dem VI anwenden, in dem das entsprechende Control existiert.
- Eine Referenz kannst du z.B. an ein SubVI übergeben, um dann in diesem SubVI die Eigenschaften oder Methoden zu ändern.

Und jetzt noch eine Ergänzung:
Ganz unrecht hast du mit Klassenhierachie nicht, denn mit den beiden Funktionen "To More Generic Class" und "To More Specific Class" kannst du schon eine Referenz allgemeiner bzw. genauer abändern.
Das ist z.B. hilfreich, wenn man sich per PropertyNode alle Referenzen aller Controls des FPs holt. Die haben nämlich anfangs nur die Klasse "Control".

Gruß, Jens

LabVIEW Controls sind natürlich Objekte (und auch also solche implementiert in C++). Die Properties und Methoden von Controls kommen dann auch sinngemäss met den Properties und Methoden von Objekten überrein. Aber das heisst nicht das das Objektinterface das ein Control zur Verfügung stellt identisch ist mit dem C++ Interface der Implementation, LabVIEW macht da schon noch einiges and syntaktischem Zuckerguss dazwischen. Die Vererbung macht hier dann auch tatsächlich Sinn: wenn man im Popup-Menu von Properties und Methoden von Controls schaut sieht man die Properties/Methoden von der mehr generieken Klasse durch einen Trennstrich von den der mehr spezifischen Klasse getrennt.

Ob die Referenz aber implizit oder explizit ist hat rein gar nichts mit Vererbung zu tun. Das ist viel mehr analog zu einer Funktion die im expliziten Fall die Objektreferenz als Parameter bekommt, und einer die im impliziten Fall die Referenz aus einer modulglobalen Variable liest (also einer Variablen die ausserhalb aller Funktionen als "static ObjectReferenz _RefName" deklariert wird und zur Initialisierungszeit des Moduls initialisiert wird). Und auch das ist mehr eine Analogie, dann ein faktisches Implementationdetail, wie LabVIEW das wirklich macht.

@Rolf: Wieder einmal vielen Dank für deine erhellenden und tiefgreifenden Erklärungen.

Gruß, Jens