Difference between LocalVariable <-> PropertyNode.Value

[Mareike]

Hi,

what is the difference (advantage/disadvantage) of using a LocalVariable or
the property "Value" from those variable?

Mareike

[Doug (CapeFl)]

Mareike,
I find if you just want to read or write the 'value' of a control or indicator, a Local Variable is all you need. However, if you want to read or write the value AND other data (properties...e.g. color, position, visibility, etc.) in the same step, a Property Node is the way to go since it a Property Node easily expands to include other elements (all in just 1 node).
A simple example of this could be if you wanted to set (write) the color of a guage and its value based on some other info - you would not want to set its value (perhaps to a Local Var) and then set its color thru a separate proeprty node, you could do all this with just one property node set to both value and color.

Doug

[Greg_McKaskle2]

> what is the difference (advantage/disadvantage) of using a LocalVariable or
> the property "Value" from those variable?
>


The most efficient place to update the value of an indicator or read the
value from a control is from the terminal. I know it is old fashioned,
but it is still the best.

If you need to read a Button in parallel loops or write to a control,
and this is being done from the panel's diagram, then you probably want
to use a local variable. If you are updating lots of other properties
and you would like to update the value at the same time, then it may
make sense to use the value property from the panel's diagram in some cases.

If you have a subVI that performs some action on one or more controls
and has references to the cont
rols, then that is the best time to use
the value property.

At this time, the value property is the slowest -- has the fewest number
of optimizations. The local is faster, but still slower than the
terminal, and the best is the terminal. The reasons for this are very
detailed and it is basically that there are many optimizations for
updating controls. The new value property doesn't have nearly as many of
the optimizations. Some or most of them will be implemented over time,
but they are not there yet.

If we are not worried about efficiency, but rather worried about code
readability, then I think they fall in the same order. The primary
access to the data should be from the terminal. Every control/indicator
has one, and that is its sole purpose. A control may have locals, and
when they do, the timing as to how these updates line up with each other
and with the terminal get harder to follow. Add in the ability for the
updates to happen from anywhere in the program at any
arbitrary time and
the bugs can get even more devious. Used properly these are very
powerful features, but overuse them and the debugging time can go
through the roof.

Greg McKaskle

[MichaelAivaliotis]

Yes, I agree about the under-utilization of the control or indicator terminals! I can't beleive how many times i've seen code where people collect all the terminals in a neat little pile in one corner of the diagram and use locals everywhere...

[Enrique]

There was a similar discussion about this topic before. Here I include some of the most relevant point:

- Property nodes have and error input and output. Changes to the property node only occur if there is no error on the input.

- The property node allows the reading and writing of a single control within a cluster whereas a local variable and terminal will always refer to the entire cluster. A property node can update the value from a remote location, not on the diagram associated with the panel. If you are using a non-strict control reference, then the datatype of the value may be a variant rather than the actual datatype of the control.

- The creation of local variable makes a copy of data and you call it's data by value. When you crate many of l
ocals, especially for complex data types like arrays, you get perfomance loss.

- Property node calls value by reference and doesn't copies the data itself. LV internal updating values mechanism is another difference.

Regards;
Enrique

[JeanPierre]

Enrique wrote:
"Property node calls value by reference and doesn't copies the data itself."

I would be surprised if this statement is true. Is it documented somewhere? Control references are *not* data pointers.

Jean-Pierre

[Enrique]

I copied those points from this previous discussion:

Local Variable vs. Property Node (Value) 

EJV

[JeanPierre]

From my understanding of LabVIEW internals, I don't beleive that the value property node is a call by reference. If a data pointer were used, it would refer to an existing copy of the data which can only reside then on the front panel control. Obviously, the front panel data won't change if you manipulate the data coming from the value property node.
Correct me if I am wrong but control references are not data pointers but references to LabVIEW objects, intended mainly to manipulate their appearance and behavior. If you read the value property, a copy is made the same way as for reading a local or a global.

Jean-Pierre

[Enrique]

... and there will be no necessity to write back to value or to any of the other attributes in the property node after manipulating the data! So, that "difference" must be revised, or even discarted at all as incorrect.

The new control reference feature in LabVIEW 6 can give the illusion that you are calling data by reference, specially when it allows you to modify the attributes of a control or indicators in the main vi from a subvi. A closer look on how it works [broken link removed] shows that are just references as you point out.

I am sorry if this mislead somebody here (I was, specially when the original sour
ce got 4 stars!) Thanks to point that out Jean.

EJV - Not ashamed of learning the hard way.