Property node and it's equivalent in C/C++

[mathewsmjohn1992]

Hey,

I am really new to LabVIEW and I am trying to learn the philosophy behind the program (Generally that helps me learn a language/software fairly fast). So far I have figured out most of the basic stuff thanks to the NI tutorials on the internet. However, I am still finding it difficult to relate most of the things to a piece of code. After exploring arrays a bit I encountered property nodes and invoke nodes. If I consider a 1D array as a class object, I guess the property nodes will be the methods of this class.

I wanted to resize the array, so I changed the number of columns of the array. This is where things get a bit fuzzy for me. On the VI, I am able to see that the new columns are created, but I am not able to access it unless they were all previously initialized. So when I change the number of columns through the property node is it not allocating any memory space for a new element or is it allocating some space with all memory pointing toi NULL? Is it even possible to resize an array in this method? I saw some 'dangerous' array resize methods online and I really want to learn what's happening so that I can be more cautious later on.

I am also attaching the VI file along with the post.

[Matthew_Kelton]

If you look at the help for that property, you will see that is is merely changing the number of elements displayed in the control or indicator.  It is purely aesthetic and has no effect on the value of the array.

There is an array primitve on the functions pallette that will allow you to resize/reshape the array.  You can also use the build array to add a row.  To add a column, you would most likely have to transpose the array, add a row, then transpose it back.

Generally speaking, it is much mro eefficient to initialize your array to the proper shape to begin with and use replace arry subset to insert data into your array.  If you are building an array from a for loop using auto indexing, LabVIEW is very efficient creating that array without you having to preallocate it.

[mathewsmjohn1992]

This makes sense. I will look into autoindexing. Also, a quick question. Does LabVIEW follow a row major format or a column major format while filling in arrays? I am assuming row major from your answer. I just want to be sure.

[natasftw]

It's row major. 

Be careful with how you visualize a property node.  If you view things as a class, the Invoke Node would act on methods.  The property node would work with properties/attributes. 

If you had a class for a rectangle, you could have an implementation like the following:

Properties:

Width:

Height

isSquare

Methods:

calcArea

calcPerimeter

calcIsSquare

WIth this rectangle, we could use property nodes to find/associate numeric values with width and height.  We'd have something similar for the boolean isSquare.  In LabVIEW, we could work with these using property nodes.  We could also call the methods listed.  In LabVIEW, we'd use invoke nodes for this.

A common equivalent to text-based languages for a property node would be a getter/setter.  You get and set property values.

[tst]

There are some important differences to understand between C/C++ and LV in this area.

The first is that LV isn't classically an OO language. It has an OO component, but that is a relatively recent addition and is something you choose to use (vaguely like the relation of C++ to C, but not really).

The second is that LV has two separate class hierarchies. One is the one you write yourself (referred to as LVOOP or LV classes) and the other is the older hierarchy used to actually describe VIs. This is called VI server and that's the one you're looking at. As Matthew suggested, in this case the object you're acting on is the array control, not the array data.

Which brings us to the third thing - LV has a different approach when it comes to data which lies at its heart - functions take, process and output data. Wires fill the same role as variables - getting the data from one place to another. You can create controls and indicators to input and show data. You can set control and indicators as function inputs and outputs.

The point is that the controls here double as both UI and data terminals. It's important to understand that manipulations on the data are always done on wires using the relevant API (array functions in this case), not on indicators and controls. You can store the data in controls and read/write it using local variables, but note that unlike in C, local variables are often a bad idea in LV, primarily because LV code is inherently parallel and it's much easier to create race conditions with locals in a parallel system.