LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

New in-place element structure option - class property node read/write - to ensure access to parent node private data is done in-place

I love lvoop but I hate that you have to suffer a huge performance hit when accessing parent class private data via access vi's, especially if it is large datastructures.  


As access vi's can also be invoked using property nodes, make a read/write property node pair accessible via an IPES - this will instruct the compiler that this access to the parent class' data should be done in-place.

Proven Zealot

Actually, no... try this on for size...


Suppose your parent class as a data field "LargeDataBlock". Create the accessor "Swap". It takes the class in AND has a class out. It has a Recommended input of type LargeDataBlock.


On the block diagram, do this:


Then, to use it, do this:


Proven Zealot

The swap size of any data type is its top-level size, so you can swap an array or string or path or *nested object* at the cost of just a pointer (4 bytes or 8 bytes depending upon system).

Active Participant

Brilliantly sneaky! And I like it as the parent vi's have direct access to the data - unlike the DVR or SEQ methods I suggested,


Now that 2013 is released (today) I might also try your first suggestion (accessor vi's that don't have error clusters or any case structures and ideally the read hasn't the class wired through).


Thanks for the interesting discussion.


Now back to 6th Str for a couple of beers...



Proven Zealot

I've thought about modifying the templates for properties to have a Read and a Swap instead of Read and Write... the Property Node syntax makes that awkward since you actually want two different read properties, one for "I'm reading this and I'm not giving it back" and "I'm reading this in order to modify it and restore it", but there's no way to express that with the property node.


The property node syntax is really awkward sometimes... I like just using the subVIs... more flexibility to express exactly what needs to be expressed, rather than try to shoe-horn into some particular syntax -- it's like having the requirment that there's only one conpane allowed for all VIs.

Active Participant
I find my guys using property nodes when there are many members to read or write on the same diagram. Then it saves real estate. But I hate it when coding decisions are made because of diagram layout considerations. From our discussion above, dropping an (swap) accessor vi down instead of using property nodes would make a lot of sense when performance is a consideration. Saw some crazy bull riding last night on 6th.
Example Gatekeeper
Status changed to: Completed
Available in LabVIEW 2013
DNatt, LV R&D