Leaderboard

Agreed. I didn't have a suitable class hierarchy immediately on hand to make a simple example, so I cheated. Trust me that it works the same way with a user-defined parent and child. There is some strangeness here, especially when you read the LabVIEW documentation about using classes with DVRs and IPEs, and the fact that PRTC is required. Absent that though, this is how I would expect it to work. A child object is technically is of the parent type, and you can mix parent and child objects in arrays, clusters, queues, etc--as long as they are of the parent type. If you really want to blow your mind, as I alluded to in my question #4 in my first post, you can get rid of the PRTC by wrapping the object in a cluster: There's a cryptic sentence in the "using references with classes" link above that says you can do this to swap objects without PRTC, but I'm not sure what's going on under the hood that makes this work, or even if it's supposed to work with child objects.

ps, Thanks for your reply. Based on what the LabVIEW DVR documentation says, I agree in principle with what you wrote. In practice it seems to do something else. I'm trying to figure out if this is expected behavior or not. I don't have a quick example to show a method override, but here's a stupid example that shows that the object mutates and preserves child class data. The DVR is a reference to an LVObject, but I use PRTC to stuff in a "Node List" object that has previously modified class data. Later on I get the object back, downcast it to Node List, and get the data out. In a larger application I was able to call an overriden method from an IPE using a similar technique.

The help mentions subarray for both outputs. A very important distinction to many of the array primitives if you're worrying about memory. I think what LabVIEW really needs is a good discussion in the help about what a subarray actually is with proper links from the primitives that can actually create subarrays. For the uninitiated, subarrays don't require new allocations of the actual array data as long as you don't go modifying the data in either the subarray or original array wires. Subarrays are indeed key to how many of the array primitives operate so efficiently-- basically they point to the same data as the original array, albeit have different scalars keeping track of each dimension in the array.

I've been using that little trick for years. I could take either side of the debate, but as a user I lean towards not having to define the output data.