UnlikelyNomad

The above bit is what gets tedious to setup for all of those property VIs, this would get used inside those VIs for outside access but for a lot of stuff I do I try to avoid the overhead of an additional VI call just to pull out a data value. Here's a clarification of the boilerplate I'm eliminating:

The key here is working with the DVRs and to speed up the boiler plate effort of multiple unbundle by names and an in place structure.

I've been working a lot lately with by-reference architectures that still cooperate completely with LabVIEW's implementation of OOP and polymorphism. I've also recently taken an interest in trying to speed up development with secondary providers (similar to GOOP) to enable automatic creation of accessor VIs hidden behind the DVR, automatic creation of the private data type and constructor/destructor, etc. within the project window. I'm generally not a fan of the extra stuff that goop adds in to classes, I'd prefer to keep the source code looking as close to a normal class as possible. That said, I've started on my first ever XNode and it's a cross between an unbundle by name node and the -> operator in C. It functions just like a normal UBN, however it was also pull items out of DVRs. Having to plop down a UBN to pull out the reference from the class, an in place node to dereference, and then another UBN to pull the data out gets tiresome after about the 100th property VI gets written. So far I've gotten the node drawing completed (except for data type coloring of the labels), the type inferencing from the input wire, and the popup menu for selecting an item. Next up will be the menu selection code so that the names will finally show up in the terminals! Then I get the daunting task of scripting up the GenerateCode ability >_> Anyone interested in something like this? Following this will be a match to the Bundle by Name node that serves the same purpose except to write the items.